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A version  of  COBOL  that  permits  structured  programming 
was  designed.  It  was  implemented  using  a pre- processor  that 
outputs  standard  COBOL-  The  pre-processor  will  indiscrim- 
inately run  programs  that  are  either  structured  or  non- 
structured,  or  with  very  limited  restrictions,  programs  with 
a mixture  of  both.  A structured  IF  was  included  as  a modi- 
fication of  the  COBOL  IF-  In  line  looping  was  created  with 
a redefinition  of  the  PERFORM,  maintaining  all  of  its  capa- 
bilities and  adding  a DO  UNTIL.  The  PERFORM  was  also 
modified  to  allow  a CASE  construct.  All  new  structures  are 
completely  nestable. 
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I.  INTBODUCTICN 

Structured  Programcaing  is  one  of  the  generally  accepted 
methods  of  reducing  software  costs,  both  of  acquisition  and 
maintenance,  while  improving  program  quality.  Until  very 
recently  the  high  cost  of  hardware  relative  to  software  re- 
sulted in  the  development  of  software  that  minimized  the 
need  for  and,  as  a result,  the  cost  of  hardware.  Today  the 
situ  tion  is  reversed  and  in  the  future  it  is  predicted  to 
even  more  one-sided.  With  the  concentration  on 
j-technology  development,  the  size  and  cost  of  computer 
hardware  has  made  a quantum  jump  downward  while  the  avail- 
able core  has  increased  almost  as  much.  At  the  same  time, 
the  size  and  complexity  of  problems  that  can  be  programmed 
have  greatly  increased.  Almost  everyone  in  the  computer 
field,  especially  those  ir  management  who  have  seen  their 
budgets  and  cost  estimates  for  software  development  and 
maintenance  soar  out  of  sight,  have  realized  something  must 
be  done. 

According  to  McGowan  (1975),  in  1975  the  U.  S.  Air 
Force  estimated  that  65%  of  its  computer  costs  went  towards 
software  and  by  1985  95%  will.  He  estimated  that  overall  10 
billion  dollars  was  spent  on  software  in  1975.  Gansler 
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hat  U.  S.  Air  Force  avionics  sottware  devel- 
re  $75  pet  instruction  while  maintenance  ot 
re  was  close  to  $4000  pet  instruction.  A 
been  shown  by  Baker  (1972a)  to  not  only 
development  costs  but  mote  importantly  to 
and  cost  of  debugging  and  increase 
is  top  down  structured  programming.  It  was 
who  first  formalized  structured  programming 
ing  discipline.  However,  it  is  a method  of 
t was  probably  unconsciously  used  by  the  best 
rs  for  years. 

SIMSCKIPT  and  other  second  generation  Ian- 
eloped*,  the  facilities  for  structured  pro- 
ncluded,  again  unconsc iously  since  the 
ctured  programming  had  not  been  formulated  at 
he  three  early  languages,  ALGOL  had  the  only 
or  structured  programming.  Unfortunately, 
implementation  and  the  opposition  and 
m a major  U.  S.  producer  of  hardware  and 
s and  is  the  least  used  of  the  three.  Most 
still  done  in  FORTRAN  or  COBOL.  These  were 
were  originally  designed  to  run  very  guickly 


*Por  the  purposes  of  this  thesis,  FORTRAN,  ALGOL,  and 
COBOL  are  defined  as  first  generation  languages  and  the 
other  major  languages  that  were  developed,  or  else 
redeveloped,  li)ie  SIMSCRIPT  was,  from  the  mid  faO's  on,  as 
second  generation  languages. 
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in  iiuidil  computers.  They  were  and  still  ate  seriously 
lacking  in  ease  of  designability  and  raa  intainability , and  as 
a result  often  have  poor  reliability.  Due  to  its  widespread 
use  in  academia  and  utter  incompatabiiity  to  the  methods  of 
structured  programming,  many  changes  for  FORTBAN  have  ueen 
recommended.  Some  liave  been  implemented  in  both  pre- 
processors and,  for  some  vendors,  in  compilers. 

COBOL  has  been  a different  story.  According  to  Yourdon 
(1975c),  little  nas  been  done  for  COBOL  because  of  disdain 
for  it  ny  the  academic  community  and  the  lack  of  research 
that  is  done  by  the  business  community  in  language  design. 
However,  recently  there  has  been  widespread  support  for 
changes  to  COBOL-  In  April  of  1975  a conference  was  held  by 
the  Programming  Language  Committee  of  CODAYSL‘,  the 
Symposium  on  Structured  Programming  in  COBOL-Future  and 
Present.  Many  proposals  were  put  forth  by  the  participants, 
ranging  from  not  changing  COBOL  at  all  (a  minute  minority) 
to  changing  it  so  much  that  it  would  resemble  PL/I.  By  the 
end  of  the  conference  it  was  generally  agreed  that  some 
changes  were  needed,  although  no  agreement  was  reached  on 
exactly  what  changes  should  be  made.  The  changes  are  not 
close  to  happening.  One  participant,  Edward  Yourdon  (1975b) 
predicted  that  it  would  be  1978  or  1979,  at  the  earliest. 
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bfffore  diiy  changes  would  be  reflected  in  any  new  versions  of 
COBOL. 

Statement  of  the  Problem 

The  purt;ose  of  this  study  was  to  design  a structured 
version  of  COBOL  and  implement  it  using  a pre-processor. 
Structured  programming  in  PL/I  was  used  to  design  and  imple- 
ment the  pre-processor.  The  considerations  used  to  design 
the  structures  were;  (1)  as  much  as  possible  redefinitions 
of  existing  COBOL  structures  were  used,  (2)  any  new  verbs  or 
structures  were  patterned  after  existing  COBOL  structures, 
and  (3)  all  existing  programs  could  be  run  against  the  pre- 
processor with  no  changes- 

Rather  than  drastically  change  the  COBOL  language, 
which  would,  most  likely,  produce  resistance  from  experi- 
enced programmers,  a gradual  change  would  allow  a more 
orderly  transition  to  a fully  structured  COBOL.  The  changes 
made  here  are  an  addition  to,  rather  than  a change  to, 

COBOL.  This  will  allow  the  training  of  new  programmers  in 
structured  programming  while  slowly  transitioning  the  old 
programmers.  All  of  the  tasic  structured  programming  struc- 
tures are  included  in  this  version  of  COBOL.  As  a future 
proposal  other  refinements  can  be  added.  Of  course,  too 
drastic  a change  to  COBOL  would  result  in  a language  so 
simiiiar  to  PL/I  that  PL/I  could  be  used  instead.  However, 
due  to  the  large  investment  in  existing  COBOL  programs,  it 
will  not  be  economically  feasible,  at  the  present,  and  prob- 


5 


ably  not  for  the  forseeaole  future,  to  replace  COBOL. 
Therefore,  not  only  is  a version  of  COBOL  needed  that  will 
allov  structured  programming,  but  also  one  that  will  run  all 
existing  COBOL  programs.  Khen  maintenance  is  done  on  exis* 
ting  programs  the  new  structures  should  be  able  to  be 
intermixed  with  the  old.  No  distinction  should  be  necessary 
between  old  and  new  programs;  they  should  all  run  under  the 
same  job  control  language  including  the  pre-processor.  The 
route  taken  in  this  study  is,  then,  to  extend  the  meaning  of 
certain  COBOL  verbs,  while  keeping  all  previous  meanings, 
and  adding  some  minor  terminators  and  optional  modifiers  for 
clarity. 


Literature  Search 

ilany  books  and  papers  have  been  written  on  structured 
programming.  In  fact,  it  is  probably  the  favorite  subject 
of  both  programming  theoriticians  and  practitioners  at  the 
present  time.  COBOL  has  been  used  almost  strictly  by  the 
business  community.  Until  recently  this  has  resulted  in  the 
absence  of  research  on  the  subject  as  cited  before  in 
Yourdon  (1975c).  The  theoretical  foundations  for  structured 
programming  in  any  language  were  laid  in  1966. 

Bohra  and  Jacopini  (1966)  showed  that  any  program  with 
one  entry  and  one  exit  (that  is,  an  algorithmic  solution  to 
a problem  as  almost  all  programs  ate)  could  be  programmed 
with  only  the  following  three  logic  structures:  simple  se- 

quence, conditional  branch  to  two  choices  (IF  THEN  ELSE) , 
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i 
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and  itecatiun  (DO  WHILE)  (Fig.  1).  Put  noire  siDi()iy,  any 
pi'ogcan,  no  matter  what  its  complexity,  can  be  written  with 
a comoination  of  these  three  structures.  Dijlistra  (1968) 
toolt  their  basic  theory  and  developed  a practical  program- 
ming methodology. 

The  Structured  Programming  presented  by  Dijkstra 
includes  using  only  the  above  three  structures-  Any  program 
can  be  developed  by  the  appropriate  nesting  of  these  struc- 
tures. The  flow  of  program  control  must  include  single 
entrance  and  exit  with  no  branching  out  of  the  flow  allowed- 
Most  practitioners  advocate  the  blacli  box  or  modular  con- 
cept (McGowan,  1975),  where  each  module,  subroutine,  func- 
tion, etc.  is  a small  easily  understood  section  of  code- 
Many  recommend  that  the  size  be  one  page  or  less.  This 
allows  for  both  easy  debugging  and  maintenance.  The  concept 
is  also  fundamental  for  top  down  programming.  This  also 
eliminates  the  forward  and  backward  referencing  of  either 
the  basic  or  conditional  GO  TO.  Dijkstra  (1972)  maintains, 
and  it  seems  obvious,  that  any  type  of  branching  out  of  the 
logic  flow  not  only  causes  the  logic  of  the  programming  to 
be  hard  to  follow  but  is  also  a chief  cause  of  error-  To 
add  to  both  the  understandability  and  readability  of  pro- 
grams, Doth  indentation  and  documentation  ate  also  required. 
For  example. 
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Fig.  1. — BASIC  STBUCTUKES 
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SIMPLE  SEQUENCE 


IF  THEN  ELSE 


1 1< 

I I i i 

I I I I 

I • 

^ * « 

— >0 >*  ♦ — > 

* * 

* 

00  WHILE 


I 


P£8F0R?1  Z100  UNTIL  A, 


Z100. 


IF  B THEN 


IF  D THEN  E 


ELSE  F 


ELSE  G, 


is  rauch  harder  to  follow  than 


PERFORM  UNTIL  A, 


IF  B THEN 


IF  D THEN 


ELSE 


H I 


END-IF 


ELSE 


END-IF 


END-PERFORM. 

Of  course  for  anyone  else  to  understand,  check,  or  change  a 
program,  it  is  much  easier  if,  at  the  beginning  of  each  sec- 
tion, is  written  what  the  programmer  thinks  the  section  will 
accomplish. 

It  has  also  generally  been  accepted  (Yourdon,  1975a  and 
McGowan,  1975)  that  extension  to  the  three  basic  structures 
be  allowed.  These  include  DO  CASE,  DO  UNTIL,  and  LOOP  EXIT- 


r - 


IF  END-LOOP  (Fig.  2).  These  do  not  dffect  the  underlying 
principles  of  structured  programming  and  will  allow  more 
efficient  coding.  Although  anything  can  be  programmed  using 
tne  three  Lasic  structures,  limiting  programming  to  just  the 
three  sometimes  results  in  awkward,  inefficient,  and 
hard-to- understand  code,  this  is  just  the  opposite  of  tne 
purpose  for  structured  programming.  Extensions  to  the  basic 
structures  are  sometimes  necessary  to  avoid  the  "turing 
tarpit"  (Couperus,  1975),  where  everything  is  possible  but 
nothing  is  easy.  Some  authors  still  feel  there  should  only 
be  a limited  number  of  structures  and  constructs  (fourdon, 
1975c).  However,  one  of  the  main  tenants  of  structured  pro- 
gramming is  that  it  allows  for  better  debugging  and  mainte- 
nance because  it  results  in  understandability  and  simplic- 
ity. What  is  simpler  than  having  one  construct  that  does 
what  its  name  implies,  yet  replaces  a group  of  complicated 
code  (as  many  of  the  advanced  constructs  in  PL/I  do)? 

Besides  a method  for  coding,  top  down  structured  pro- 
gramming is  also  an  overall  programming  strategy.  Most  pro- 
gramming has  been  traditionally  done  with  a bottom  up  ap- 
proach where  the  lowest  level  programs,  subroutines,  or  sub- 
systems were  designed,  coded,  and  tested  first.  These  pro- 
grams needed  driver  programs  to  test  them  and  tor  integra- 
tion testing  with  parts  that  other  programmers  had  written. 
Problems  often  occurred  during  integration  because  of 
inconsistent  data  definitions  and  interlaces  (McHenry, 
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Fig.  2. — EXTENDED  STBUCTORES 
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1973).  The  whole  system  was  sometimes  delayed  while  impor- 
tant seyments  were  reworked  to  allow  proper  interfacing. 

The  top  down  approach,  as  the  name  implies,  is  just  the  op- 
posite. 

Top  down  programming  follows  the  natural  systems  ap- 
proach (Yourdon,  1975a  and  McGowan,  1975).  The  system  is 
broken  down  into  a tree  structure  (Fig.  3) . First  the 


Fig.  3. — TOP  DOWN  DESIGN 
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major  functions  are  identified  (A).  From  there  the  next 
level  down  is  identified,  lesser  functions  (B)  derived  from 
those  above  it.  At  the  same  time  the  interfaces  and  data 
definitions  are  defined.  During  this  development  all 
undefined  or  uucoded  segments  or  branches  of  the  tree  are 
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replaced  with  a damiiiy  stub.  For  example,  if  the  interface 
is  in  the  form  of  a procedure,  when  the  procedure  is  called, 
a laessa^je  or  a dummy  value  is  returned.  This  allows  the 
system  to  be  continually  tested  as  the  development  proceeds. 
Since  many  errors  occur  in  the  interfacing,  they  are 
removed  early  in  tne  development  since  they  will  be  the  most 
tested  part  of  the  system.  Each  time  the  system  is  tested 
all  that  was  completed  before  is  tested  again.  This  is  com- 
pared to  the  traditional  bottom  up  method,  where  the  overall 
system  is  not  tested  until  the  end  of  the  development,  and 
at  that  point  it  may  be  difficult  to  pinpoint  where  the 
problem  is. 

The  method  was  first  used  in  the  now  famous  New  York 
Times  project  (Baker,  1972a  and  1972b).  The  project  in- 
volved the  automation  of  the  New  York  Times  morgue.  It  was 
to  take  the  newspaper's  clipping  file  and,  via  a thesauras 
and  abstracts,  have  an  on-line  capaniiity  of  search  and  re- 
trieval, with  the  added  capability  to  retrieve  the  original 
article  on  microfiche  and  display  it  at  the  remote  on-line 
terminal.  The  final  system  required  more  than  83,000  source 
lines  of  code.  It  took  132  man-months  of  effort.  Using 
normal  projections  and  the  generally  accepted  figure  of  five 
lines  of  code  per  man-day,  the  project  under  old  methods 
would  have  taken  over  500  man-months.  To  add  to  this  was 
the  fact  that  the  system  had  an  historic  low  error  rate, 
with  most  of  these  errors,  as  could  be  expected  using  top 
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down  design,  in  the  lowest  level  and  least  tested  code, 
these  also  turned  out  to  be  the  easiest  to  fix  with  no  error 
taking  more  than  one  day  to  correct.  Equally  impressive 
results  were  obtained  in  a second  project,  the  mission  simu- 
lation of  Skylab  for  NASA. 

Structured  COBOL 

All  of  the  above  literature  were  on  the  general  topic 
of  structured  programming  and  did  not  address  the  problem  of 
structured  programming  in  COBOL,  except  for  McOowan  (1973) 
and  Yourdon  (1975a).  They,  together  with  McClure  (1975)  and 
numerous  other  authors  in  journals  and  recent  publications, 
included  small  sections  on  how  to  simulate  structured  COBOL 
for  those  constructs  in  COBOL  which  hinder  or  prevent  struc- 
tured programming  from  being  attained.  In  most  cases,  the 
authors  recommend  tnat  COBOL  be  changed,  although  few  give 
specifics  on  how  it  should  be  changed.  Some,  such  as 
Kauffman  (1)75),  recommend  that  a pre-processor  be  written 
and  used  until  the  official  language  changes  are  made  and 
incorporated  into  compilers.  Ail  of  the  serious  proposals 
for  changes  to  COBOL,  in  regard  to  structured  programming, 
were  presented  at  the  1975  COOASYL  conference. 

Although  some  authors  added  a few  of  their  own  specific 
examples  of  COBOL  code  that  hindered  structured  programming, 
almost  unanimous  agreement  was  shown  for  four  serious 
shortcomings  of  COBOL,  These  are;  (1)  there  is  insuffi- 
cient blocking  capability,  which  partly  results  in  the  next 
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two  shortcoaiu js,  (2)  the  IF  THEN  ELSE  can  not  be  fully 
nested  and  as  a result  does  some  unexpected  things,  (3) 
there  is  not  a method  for  performing  in-line  loops,  and,  (4) 
there  are  no  capabilities  for  the  DO  UNTIL  and  CASE  struc- 
tures. Although  there  was  agreement  on  the  main  problems, 
there  was  none  in  the  proposed  solutions  to  each  of  the 
above  problems.  Many  solutions  did  not  fit  the  criteria 
that  were  previously  established.  Others  were  contradictory 
to  what  the  majority  felt  were  needed.  A fourth  considera- 
tion for  designing  the  language  was  thus  added  to  the  origi- 
nal three.  The  structures  should  be  those  that  are  likely 
to  be  adopted  in  the  official  COBOL  language,  therefore  al- 
lowing as  much  compatibility  as  possible  for  the  future. 

The  tollowing  articles  were  considered,  along  with  those 
previously  mentioned,  when  this  structured  version  of  CuBOL 
was  designed. 

Benning  and  Nead  (1975)  made  the  broadest  proposal. 

They  proposed  to  use  labeled  BEGINS  and  ENDs  to  designate 
blocks  in  all  structures.  This  would  solve  the  problem  of 
noth  the  IF  THEN  ELSE  and  the  in-line  PEHFORM,  in  the  in- 
line PERFORM  using  PERFORM  block...  with  the  BEGIN-END  form- 
ing the  block.  They  also  recommended  a CASE  structure  en- 
tirely independent  of  the  PERFORM.  They  suggested  allowing 
arguments  for  the  PERFORM  and  changing  the  AT  END  to  an  IF 


I 
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statement 


I 

I 

I 
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I 
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Couperus  (iy75)  only  suggested  udding  a CASE  statement 
by  allowing  subscripted  labels.  Then  either  the  CO  TO  or 
the  PEHFOBM  could  be  used  to  operate  on  the  subscripted 
laoel. 

Goguen  (1975)  recommended  local  terminators  to  solve 
the  blocking  problem.  They  would  include  the  EUD-IF,  END- 
PEBFOHM,  END-KEY,  END-ON,  and  END-AI.  The  END-IF  would 
solve  the  problem  of  the  nested  IF  THEN  ELSE.  She,  as  did 
Benning  and  Nead,  suggested  an  in-line  PERFORM,  out  used  the 
END-PEHFOFM  to  delimit  it.  She  recommended  retaining  the 
UNTIL  and  adding  a WHILE,  which  would  be  its  exact  opposite, 
and  appears  a little  superfluous-  These  two  would  form  the 
DO  WHILE  structure.  To  have  a DO  UNTIL  structure,  she  would 
add  a REPEAT  UNTIL  at  the  end  of  the  PERFORM  loop.  To  add  a 
CASE  structure,  the  GO  TO  DEPENDING  ON  and  the  PERFORM  were 
combined  into  a PERFORM  DEPENDING  ON...  with  the  target  a 
group  of  subscripted  CASE'S.  The  AT  END,  GNSIZE  ERROR,  and 
INVALID  KEY  would  be  changed  by  having  local  terminators 
END-AT,  END-ON,  and  END-KEY.  One  final  change  would  be 
making  EXIT  a return  from  anywhere  in  a paragraph  being 
PEBFORMed. 

Hide  and  Croes  (1975)  made  some  PL/I  type  suggested 
changes.  To  solve  the  blocking  problem,  they  proposed  local 
terminators,  CLOSE-IF,  CLOSE-WHILE,  CLOSE-LOOP,  and  CLOSE- 
PROCEDURE.  Along  with  the  CLOSE-IF,  they  would  add  an 


ELSEIF  to  solve  the  nested  IF  problem,  however  there  does 
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not  seem  to  be  much  advantage  to  adding  anotner  reserved 
word.  In  tact,  they  did  not  really  specify  what  would  be 
the  difference  between  their  new  ELSEIF  and  the  normal  ELSE 
IF.  It  just  seems  harder  to  read.  Rather  than  allowing  an 
in-line  PERFORM,  they  would  add  a myriad  of  other  con- 
structs, WHILE,  REPEAT  UNTIL,  LOOP,  DO,  and  PROCEDURE,  each 
as  a stand  alone  verb  with  their  own  individual  local 
terminators. 

Hicks  (1975),  as  with  most,  would  use  local  terminators 
to  obtain  blocking.  His  choice  of  terminators  was  quite 
unique,  however.  He  would  reverse  the  normal  IF  THEN  ELSE 
and  have  IF  ELSE  THEN,  The  conditional  and  true  part  would 
fall  between  the  IF  and  ELSE  and  the  false  pact  between  the 
ELSE  and  THEN,  with  normal  program  flow  continuing  after  the 
THEN.  He  would  also  allow  the  ELSEIF  that  Hide  and  Croes 
suggested.  Instead  of  changing  the  PERFORM,  he  would  have  a 
general  loop  with  the  exit  allowed  anywhere  in  it.  It  would 
take  the  form  of  LOOP  ...  EXIT  ...  REPEAT.  The  EXIT  with  a 
conditional  could  be  moved  anywhere  in  the  loop,  so  that  to 
obtain  a DO  WHILE  construct  the  EXIT  would  be  at  the  top,  a 
DO  UNTIL  construct  would  have  the  exit  at  the  bottom.  This 
seems  to  be  a very  flexible  idea. 

McComas  (1975)  would  prefer  blocking  like  Bening  and 
Nead  suggested,  the  BEGIN  and  END.  However,  he  would  not 
label  them.  He  would  eliminate  the  PERFORM  altogether.  He 
would  replace  the  call  function  of  it  with  internal  proce- 
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I duces  and  the  expansion  of  CALL  to  include  internal  proce- 

dures. The  loopin'j  function  of  PERFORM  would  be  replaced 
I with  DO,  redefining  UNTIL  and  adding  WHILE,  CASE,  and  TIMES. 

I To  add  one  more  PL/I  type  change,  he  would  do  away  with  the 

A-margin  and  require  labels  to  be  followed  by  a colon. 

I McOuinness  (1975)  would  have  local  terminators  also. 

The  END- IF  would  terminate  the  IF  and  allow  for  complete 
nesting.  An  in-line  PERFORM  would  be  allowed  with  END- 
PERFORM  terminating  it.  The  AT  END,  INVALID  KEY,  and  ONSIZE 
ERROR  would  all  be  changed  to  implied  IF  statements.  That 
is,  there  would  be  an  assumed  IF  in  front  of  each  one.  This 
would  allow  the  use  of  ELSE  and  END-IF  after  them, 
j Orr  and  Neely  (1975)  also  recommended  the  local 

terminators  END-IF  and  END-PERFORM  to  solve  the  blocking, 

^ nested  IF,  and  in-line  PERFORM  problems.  They  would  make 

I CASE  a sepecate  verb  and  would  have  it  in  the  form  CASE  SE- 
LECTION   END-SELECTION.  They  would  also  like  to  see  a 

I feature  for  in-line  expansion  added  to  the  COBOL  language. 

I 
I 
I 
I 
I 
I 


I 

I 

I 

I 
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I 
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II.  LAN^iUAGE  DESIGN 

The  primary  considerations  for  the  proposed  change  to 
CJDOL  have  been  given  earlier.  To  review  the  criteria,  (1) 
as  much  as  possible  redef initions  of  existing  COBOL  struc- 
tures would  be  used,  (2)  any  new  verns  or  structures  would 
be  patterned  after  existing  COBOL  structures,  (3)  ail  exis- 
ting programs  could  be  run  against  the  pre-processor  with  no 
changes,  and  (4)  the  structures  should  be  those  that  are 
likely  to  be  adopted  in  the  official  language.  A careful 
analysis  of  the  problems  in  COBOL  already  presented  show 
that  the  blocking  problem  is  throughout  COBOL.  However,  as 
far  as  structured  programming  is  concerned,  in  any  language, 
the  critical  structures  are  the  IF  THEN  ELSE  and  looping. 
Although  some  of  the  suggestions  were  for  a general  block 
structure,  such  as  the  BEGIN-END,  this  would  be  a drastic 
cnange  to  COBOL,  and  except  for  the  just  mentioned  two 
structures,  the  Paragraph  and  Section  constructs  already 
constitute  at  isast  a type  of  blocking-  Thus  local 
terminators  were  used  in  this  design.  The  two  selected  were 
END-IF  and  END-PEaF08M.  The  use  of  the  END  was  because  of 
the  precedent  in  COBOL  of  the  END  DECLARATIVES.  The  naming 
of  particular  ENDs  was  used  to  allow  better  distinction  of 
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which  block  was  ending  and  to  avoid  ambiguity-  The  use  of 
the  hyphen  was  to  avoid  a possible  problem  when,  as  often 
occurs,  the  IF  THEN  ELSE  is  not  followed  by  a period.  The 
addition  of  the  second  IF  or  PEBFOBH,  could  result  in  an  END 
IF  IF  or  END  PERFORM  PERFORM  situation,  which  would  tend  to 
be  forgotten  or  to  be  confusing-  The  use  of  tnese  two  local 
terminators  also  solves  the  problems  of  the  nested  IF  THEN 
ELSE  and  in-line  loops-  To  add  a DO  UNTIL  and  CASE  con- 
structs without  adding  whole  new  constructs  and  local 
terminators,  additions  to  the  PERFORM  verb  were  made-  As  it 
turns  out,  then,  all  changes  could  be  made  using  criterion 
one  and  it  was  not  necessary  to  use  criterion  two-  Criteria 
three  and  four  are  diseased  under  the  individual 
redefinitions. 

XF_THEN_ELSE 

The  easiest  redefinition  to  make  was  in  solving  the 
nested  IF  THEN  ELSE  problem.  As  can  be  seen  in  the  Struc- 
tured COBOL  section  of  this  thesis,  the  great  majority  of 
authors  favored  adding  a local  terminator  to  close  the  IF 
THEN  ELSE;  specif icially  END-IF  was  favored.  Thus  criterion 
four  was  complied  with.  As  can  be  seen  from  the 
redefinition  and  as  explained  below,  criterion  three  was 


also  satisfied 


20 


t 

I 

I 

I 

( 

! 

I 

I 

I 

I 

I 

I 

I 

I 

I 


FOHrtAr 

(statement- 1 } (statement-2  } 

IF  condition  [THEN]  { } ELSE  { } 

(NEXT  SENTENCE)  (NEXT  SENTENCE) 

£ END-IF  ] 

The  restrictions  that  make  it  possible  to  run  all  old  pro- 
grams against  the  pre- processor  follou-  All  of  those  that 
are  listed  in  the  present  official  COBOL  language-  If  the 
optional  END-IF  is  used,  THEN  becomes  mandatory.  Any  type 
sentence  is  allowed  in  either  the  true  part,  between  the 
THEN  and  ELSE,  or  the  false  part,  between  the  ELSE  and  the 
END-IF.  Complete  nesting  of  IF  statements  can  occur  in 
either  part.  Of  course,  no  periods  are  allowed  as  this 
would  terminate  the  IF  statement  as  in  official  COBOL.  Thus 
all  criteria  tor  design  have  been  met. 

In-Line  Looping 

Although  there  was  not  as  great  a majority  of  authors 
who  preferred  the  in-line  PERFOBM  for  the  generalized  solu- 
tion to  the  in-line  looping  problem,  there  were  a signifi- 
cant number  who  did.  Also  there  was  no  consensus  of  those 
who  preferred  the  in-line  PERFOBM  on  what  form  the  changes 
should  take.  Therefore  the  simplest  and  most  straightfor- 
ward change  was  accomplished.  To  be  consistent  with  the  IF, 
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FORMAT  2 


PERFORM  [ procedure-naine- 1 THRU  procedure- ua ae- 2 ] 
(inteyer-1  ] 

{ ) TIMES  [sentences  END-PEBFOHM] 

{identifiet-1} 


The  only  chanye  is  the  addition  of  the  in-line  capability. 

As  above  THfi'J  ptoced ure- name- 2 is  only  allowed  when 
procedure- name- 1 is  used  and  when  procedure-name- 1 is  used 
nothing  is  allowed  after  TIMES. 

Format  3 has  added  to  it  the  capability  for  the  DO 
UNTIL.  When  UNTIL  is  used  in  COBOL,  the  structure  that 
results  is  actually  a DO  WHILE  since  the  condition  is 
checked  before  entering  the  loop.  Since  the  object  was  to 
minimize  the  changes  to  COBOL  and  a redefinition  of  UNTIL 
would  both  tend  to  confuse  and  would  create  problems  in  run- 
ning old  programs,  the  problem  occurred  about  which  word  to 
use  to  implement  the  DO  UNITL.  The  problem  has  been  dis- 
cussed before.  Tompkins  (1975)  points  out  while  and  until 
do  not,  ry  any  stretch  of  the  imagination,  connotate 
"zero-or-more"  or  "one-or-more".  In  fact,  in  any  literal 
interpretation,  they  are  logical  opposites.  He  suggests 
that  they  should  be  used  as  inverses  and  that  a new  looping 
structure  of  REPEAT  WHILE  and  REPEAT  UNTIL  be  used  as  the 


"one-or-more”,  with  the  DO  being  the  "zero-ot-more" . This 
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would  be  fine  for  u lunguage  like  PL/I  where  a DU  construct 
is  already  present.  However,  since  this  type  of  change  is 
not  wanted  for  COBOL,  the  word  BEFORE  was  chosen  as  having 
the  closest  meaning  to  imply  ''one-ot-more*'.  Format  3 thus 
becomes. 


FORMAT  3 


PERFORM  [ proced ure-name- 1 THRU  procedure-name- 2 ] 
{UNTIL  } 

{ } condition-1  [sentences  END-PERFORM] 

{BEFORE} 


with  no  other  restrictions  or  changes  except  for  those  in 
the  previous  two  formats.  Format  4 has  no  changes  except 
for  the  addition  of  the  in-line  capability.  It  also  has  no 
additional  restrictions  or  changes  as  shown  below: 

1 

I FORMAT  4 

I 

I PERFORM  [ procedure-name- 1 THRU  ptocedure-na me- 2 ] 

I • 

1 [sentences  END-PERFORM] 


The  capability  that 
was  the  CASE  construct, 
the  other  formats,  so  an 


was  to  be  added  to  the  perform  verb 
It  did  not  easily  fit  into  any  of 
additional  format.  Format  5,  was 
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add'jd.  Pol  the  authuLS  that  did  dddin^j  a CASH  con- 

struct there  was  no  agreement  on  either  the  form  of  the  CASK 
statement  or  the  label  targets.  Thus  the  simplest  form  was 
chosen,  again  in  the  hope  that  this  would  result  in 
compa tao il i t y with  any  official  changes.  In  this  case,  this 
was  the  closest  to  compliance  to  criterion  four  that  could 
be  obtained.  The  resulting  format  is  as  follows. 


I 1 

1 FORMAT  5 1 

PERFORM  CASE  identi fier- 1 (ar it hmet ic- expression) 

identifier- 1 ( 1)  [statements 

ident  if ier- 1 (2)  statements 

• 

• 

m 

identifier- 1 (n)  statements] 

END-PBRFORM 

The  suDscripted  identifier-1  must  have  consecutive  sub- 
scripts from  1 to  N,  where  N is  greater  than  or  equal  to  1. 
The  statements  after  the  subscripted  identifier-!  are  op- 
tional. As  a result  a statement  may  have  more  then  one  sub- 
script identifying  it,  allowing  more  flexibiltiy.  This  is 
limited  by  the  fact  that  the  subscripts  must  be  consecutive. 
Periods  are  optional  after  the  arithmetic  expression,  after 
each  subscripted  identifier,  at  the  end  of  each  statement, 
and  at  the  end  of  the  construct,  after  END-PERFORM. 
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There  are  a few  other  restrictions  on  all  of  the  above 
new  constructs  and  redefinitions  that  are  a result  of  imple- 
mentation by  a pre-processor.  The  first  was  mentioned  for 
some  of  the  individual  redefinitions  but  applies  throughout. 
The  restriction  in  COBOL  that  no  periods  appear  in  an  IF 
statement  or  else  the  IF  statement  is  terminated  applies 
equally  for  any  of  the  structured  constructs.  This  should 
not  affect  any  programs  and  should  not  in  any  way  hinder  the 
use  of  any  of  the  structured  constructs.  All  will  work  with 
no  periods  in  them.  Programmers  must  be  aware  that  when 
they  are  programming  in  an  IF  statement,  that  they  use  no 
period  until  after  the  END-IF.  A second  restriction  is  that 
no  labels  starting  with  Z are  allowed-  These  are  reserved 
for  the  pre-processor.  The  following  reserved  words  are 
also  added:  END-IF,  END-PEBFORM,  BEFORE,  and  CASE.  The 

only  other  restriction  is  that  a structured  PERFORM  not  be 
used  in  a non-structured  IF  statement.  This  restriction 
should  not  matter  to  programmers  writing  a new  program, 
since  they  should  be  using  either  all  structured  or  all  non- 
structured  programming.  It  might  atfect  a programmer  doing 
maintenance  on  an  old  program-  Any  time  a structured  PER- 
FORM is  add^d  to  an  old  program,  the  programmer  must  insure 
that  it  is  not  within  an  IF  statement  or  else  the  IF  state- 
ment must  also  be  re-written.  The  reason  for  this  restric- 
tion is  the  pre-processor  will  sometimes  add  periods  when 
processing  a structured  PERFORM.  These  periods  are  taken 


care  of  when  the  structured  IF  is  processed,  so  they  do  not 
affect  the  structured  IF.  The  removal  of  these  restrictions 
and  further  additions  to  COBOL  are  discussed  in  the  conclu- 
sion of  this  thesis. 
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III.  PRE-PROCESSOR  IMPLEMENTATION 

This  chapter  describes  the  PL/I  program  (Appendix  A) 
that  implements  the  pre- processor.  PL/I  was  used  for  two 
reasons;  one,  it  is  a language  designed  for  character  ma- 
nipulation while  COBOL  is  not,  and,  two,  it  is  a language 
that  can  be  programmed  using  structured  programming  and  thus 
would  be  a good  example  to  show  structured  programming 
methods.  Top  down  design  was  also  used  to  design  the  pro- 
gram. Many  changes  were  made  between  the  original  top  down 
design  and  the  final  design  that  corresponds  to  the  final 
program. 

The  major  reason  that  the  top  down  design  had  to  be 
completely  reworked  was  a result  of  the  same  problem  that 
caused  the  previouly  discussed  restrictions.  The  problem  is 
that  no  periods  are  allowed  in  the  IF  statement.  This  meant 
that  in  the  processing  of  the  structured  IF's  and  PERFORMS, 
when  nesting  occurred  some  way  had  to  be  found,  in  rewriting 
the  mixture  of  the  two,  to  have  no  periods,  yet  to  still 
have  proper  blocking.  The  only  fairly  simple  method  that 
was  found  involved  taking  the  original  design,  which 
intermixed  the  processing,  and  separating  it  into  two  joo 
steps.  Thus  in  essence  two  programs  were  written.  This  is 
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shown  in  Fig.  4 where  an  immediate  breaking  into  two  sepa- 
rate parts  at  the  top  of  the  design  tree  occurs.  The  rest 
of  the  design  can  be  seen  in  Fig.  4 and  the  two  separate  job 


steps  are  explained  below. 


IF  Processing 


The  first  job  step  scans  the  source  program  for  IF 
statements.  It  prints  out  the  source  listing  as  it  scans, 
if  reguested.  Each  IF  statement  is  checked.  If  it  is  a 
structured  IF  then  it  is  processed,  if  not  it  is  ignored. 

The  general  scheme  is  that  statements  between  the  THEN  and 
ELSE  and  the  ELSE  and  END-IF  are  moved  to  a paragraph  at  the 
end  of  the  source  program  and  are  replaced  with  a PERFORM  of 
that  paragraph.  Nesting  can  occur  as  many  times  as  neces- 
sary. After  this  job  step,  all  structured  IF  statements  end 
up  in  the  form:  IP  condition  PERFORM  label-Zn  THRU  label- 

Zn+1  ELSE  PERFORM  label-Zm  THRU  iabei-Zm+ 1 . Since  ail  other 
statements,  including  structured  PERFORM  statements,  are  in 
the  PSRFOEMed  paragraphs  at  the  end  of  the  source  program, 
tney  can  be  processed  in  a second  job  step  regardless  of 
periods. 

The  only  executable  statement  in  the  main  program  of 
the  first  job  step  is  a call  of  SCAN.  This  initiates  all 
other  execution  through  calls  cn  procedures.  At  the  begin- 
ning of  each  procedure  there  is  a small  paragraph  that 
explains  what  each  procedure  does.  The  three  main  proce- 
dures are  called  PROCESS_IF,  NEST_SCAN,  and  NEST_IF.  The 
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PROC£SS_IF  is  called  from  the  main  scan  any  time  an  IF  is 
encountered.  Unless  it  has  already  been  determined  that  the 
present  statement  is  a structured  IF,  by  the  presence  of  a 
IHEU  in  the  same  line,  the  source  pcoyram  is  searched  for  a 
THEN  or  an  ELSE-  An  IF  statement  that  has  a THEN  in  it  is 
processed  the  same  whether  it  is  actually  a structured  IF  or 

not.  When  an  ELSE  is  found  first,  it  means  that  the  present  ; 

5 

statement  is  not  a structured  IP  so  a return  without  proc* 
essing  is  made.  The  IF  is  transformed  into  the  form  given 
above  and  then  NESr_SCAN  is  called  to  build  the  paragraph. 

NEST  SCAN  builds  the  paragraph  until  either  another  IF  is 
encountered  or  else  an  ELSE,  END-IF , or  period  is  encoun- 
tered. If  any  of  the  latter  three  is  found,  then  a return 
is  made  to  P80CESS_IF,  where  the  completion  of  processing  is 
done.  If  an  ELSE  has  been  returned,  it  will  be  necessary  to 
build  another  paragraph  so  PR0CES3_IF  is  called  again. 

If,  back  in  NEST_SCAN,  an  IF  had  been  found,  a differ- 
ent processing  path  must  be  taken.  In  this  case  since  a 
paragraph  is  being  built  at  the  end  of  the  source  program, 
it  is  necessary  to  have  a procedure  which  will  consecutively 
build  new  paragraphs  at  the  end  of  the  string  that  is  being 
built;  this  is  NEST_IF.  Its  operation  is  almost  exactly 
like  that  of  PROCESS_IF  except  instead  of  building  the  IF- 
PERFOEM  in  the  middle  of  the  source  program,  it  does  all  its 
operations  at  the  end  of  the  source  program.  It  also  turns 
out  that  for  simplicity  and  for  core  size  savings,  it  is 
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better  to  dump  each  paragraph  as  it  is  completed,  so  that 
some  paragraphs  will  end  up  ahead  ot  the  paragraphs  from 
which  they  are  performed.  This  only  occurs  at  the  end  of 
the  original  program,  however,  and  does  not  afreet  anything 
except  readability. 

PERFORM  Processing 

The  secojid  job  step  takes  the  output  from  the  first  job 
step  and  scans  it  for  structured  PERFORMS,  processing  them 
as  encountered.  Since  all  of  the  structured  PERFORMS  have 
already  been  removed  from  the  structured  IFs  and  are  not  al- 
lowed in  the  unstructured  IFs,  it  is  a simple  matter  to 
change  all  of  the  in-line  PERFORMS  into  a PERFORM  of  a 
paragraph.  The  paragraph  is  inserted  immediately  after  the 
PERFORM,  using  a 00  TO  to  remove  the  paragraph  from  the 
stream  ot  the  program.  All  of  the  PERFORMS  except  for  the 
CASE  are  transformed  into  the  following  form. 

PERFORM  Zn  THRU  Zn+1  conditions. 

00  TO  Zn+  1. 

Zn. 

sentences. 

Zn+  1. 

The  only  additional  processing  reguired  is  for  the  PERFORM 
BEFORE.  In  this  case  an  additional  simple  PERFORM  on  the 
paragraph  is  added.  This  insures  at  least  one  execution  of 
the  paragraph.  A large  part  of  the  job  step  is  used  to  keep 
the  labels  straight  in  nesting  situations. 
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Another  large  part  of  the  job  step  is  used  in  the  proc- 
essing of  the  PERFORM  CASE.  To  implement  the  CASE,  the  GO 
TO  DEPENDING  ON  was  used.  However,  the  target  of  a GO  TO 
DEPENDING  ON  is  very  limited;  only  an  identifier  of  four 
digits  or  less  with  a limited  USAGE  is  allowed.  To  add  the 
flexibility  that  is  allowed  by  the  definition  of  the  PERFORM 
CASE  given  in  the  last  chapter,  the  pre-processor  adds  an 
identifier,  named  CASE,  in  the  working  storage  section.  The 
target  for  the  CASE,  c n arithmetic  statement,  is  assigned  to 
the  variable  CASE  ia  a COMPUTE  statement.  The  form  that  the 
processed  CASE  takes  is  as  follows: 

COMPUTE  CASE  = (arithmetic  statement). 

GO  TO  Zn. 
case- label- 1 . 
statements. 

GO  TO  Zn+  1. 
case-label-2. 

case- label-n. 

statements. 

GO  TO  Zn*  1. 

Z n. 

GO  TO  case-label- 1 , 
case- lauel- 2 , 
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case-iat)el-n, 

DEPENDING  ON  CASE. 

Zn+  1. 

The  liberal  use  of  GO  TOs  in  the  processing  of  the  PER- 
FORMS does  not  result  in  a structured  product.  However, 
this  output  is  invisible  to  the  programmer.  It  does  have 
the  advantage  of  putting  the  processed  code  in  the  position 
corresponding  to  its  position  in  the  input,  thus  allowing 
for  easier  debugging.  As  in  the  first  job  step,  all  proce- 
dures have  an  explanation  of  what  they  do  at  their  beginning 
in  the  program  listing.  PHOCESS_PERFOEM  and  NEST_SCAN  have 
about  the  same  purposes  as  the  corresponding  procedures  in 
the  first  job  step.  They  are  not  as  complicated  and  there 
is  no  need  for  a procedure  corresponding  to  N£ST_IF,  since 
there  is  no  need  to  distinguish  between  any  nested  PERFORMS 
as  they  all  will  be  put  in-line  in  the  source  program. 

Appendix  B is  a COBOL  program  that  is  written  using  the 
structures  defined  here.  Appendix  C is  the  same  program 
after  it  has  been  processed.  Appendix  D is  a user’s  manual 
for  the  pre-processor. 
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i IV.  CONCLUSICKS  AND  RECCMMEN DA TIONS 

I 

These  chainjes  to  COBOL  need  to  be  adopted  into  the 
j official  COBOL  language  and  implemented  into  the  COBOL  com- 

pilers as  soon  as  possible.  The  advantages  of  structured 
j programming  that  have  been  given  here  and  shown  to  work  in 

some  of  the  projects  listed,  prove  that  there  are  definite 
cost  savings  and  increased  reliability  resulting  from  its 
use.  The  longer  the  delay,  the  more  unstructured  programs 
will  be  written  which  will  have  to  be  maintained  in  the 
j future.  The  major  obstacle  seems  to  be  the  disagreement  on 

exactly  what  changes  need  to  be  made.  As  seen  in  the  ig7b 
conference,  in  many  cases  there  is  wide  disagreement  on 
I which  structures  are  needed  and  how  they  should  be  imple- 

mented. The  changes  suggested  here  are  a minimum  that  will 
I allow  good  structured  COBOL  to  be  written.  They  also  have 

the  advantage  of  offering  the  least  change  to,  and  are  the 
^ closest  to  keeping,  the  traditional  COBOL.  Thus  they  have 

I the  best  chance  of  being  accepted.  Any  change  to  a language 

should  be  evolutionary,  both  because  of  the  investment  in 
I programs  and  to  keep  the  retraining  and  transitioning  as 

simple  as  possible.  If  any  drastic  or  revolutionary  changes 
I to  a language  are  needed,  it  is  probably  best  to  go  to  a 
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completely  new  language,  thereby  making  a clean  break  with 
old  methods  and  any  tad  habits  that  may  have  evolved. 

The  advantages  of  implementing  these  changes  in  a com- 
piler as  soon  as  possible  are  twofold;  it  will  increase 
coding  efficiency  and  it  will  remove  those  restrictions  that 
had  to  be  made  because  of  the  pre- processor . Since  the 
local  terminator  is  present  in  the  IF,  it  should  be  possible 
to  implement  the  compiler  with  no  restrictions  on  the  use  of 
periods  in  the  IF  THEN  ELSE.  This  will  allow  better  reada- 
bility and  make  tne  program  easier  to  follow,  a definite 
goal  of  structured  prograniiring. 

The  only  other  constructs  whose  value  would  make  them 
candidates  foe  implementation  in  the  near  future  would  be 
allowing  an  exit  in  the  middle  of  a loop  as  suggested  by 
Hicks  (1975)  and  explained  in  the  first  chapter,  and  adding 
local  terminators  tor  the  AT  END,  CN3IZE  EEBOR,  and  INVALID 
KEY  as  suggested  oy  Goguen  (1975).  Of  the  two,  the  first 
would  probably  have  the  most  usage  and  therefore  should  be 
implemented  first. 

This  study  has  examined  structured  programming  and  its 
possible  use  in  COBOL.  Recommendations  for  changes  to  COBOL 
to  allow  structured  programming  have  been  made  and  imple- 
mented in  a pre-processor.  They  definitely  need  to  be 
accepted  and  implemented  into  the  official  language.  Until 
this  is  done,  the  pre-processor  can  be  used  to  attain  struc- 
tured programming  in  COBOL. 
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SOUHCE  LISTING  OF  THE  PfiE-PHOCESSOR 
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ES  A SIHUCTURED  VERSION  Of  COBOL  AND 
T INTO  ANSI  COBOL. 


EP  PROCESSES  ALL  IF  SIATEttENlS  INSURING 
NESTING  IS  OCCUBING.  V 

MAIN: 

PROCEDURE  OPTIONS  (MAIN)  REORDER; 

DECLARE  FILLER  CHA RACT ER (6 9)  INITIAL ('.  •); 

/*  FILLER  IS  USED  TO  PAD  A CHAKACIER  STRING  WITH  A PERIOD 
AND  BLANKS  WHERE  NECESSARY.  V 

DECLARE  ENDING  CHA RACT EB  ( 1 ) ; 

/♦  ENDING  IS  A PLACE  TO  PUT  A ELANK  OR  PERIOD.  V 

DECLARE  CARD  CHARACTER  ( 1 60)  VARYING  I NI TI AL  ( ( 1 60 ) * •); 

/*  CARD  HOLDS  THE  INPUT  CARD  IMAGE  PADDED  WITH  BLANKS.  V 

DECLARE  BLANKS  CHARACTER ( 160)  I N IT I A L { ( 1 6 0) • '); 

DECLARE  COUNT  PICTURE  *999*  INITIAL  (500)  ; 

/*  COUNT  HOLDS  THE  CURRENT  LABEL  COUNT.  ♦/ 

DECLARE  STARS  CHARACTER (80)  INI T lAL ( (8 0)  • ♦ • ) ; 

ON  STRINGBANGE  PUT  DATA; 

OPEN  FILE(ERRORS)  PRINT; 

/*  ERROR  MESSAGES  ARE  PRINTED  OUT  ON  ERRORS.  */ 

/*  OTHER  FILES  USED:  OUTPUT  IS  WHERE  THE  NON- 

NESTED SOURCE  IS  STORED, 

BOTTOM  IS  WHERE  ALL  NESTED 
SOURCE  IS  PLACED,  IT  IS  CONCATENATED  TO 
OUTPUT  IN  THE  NEXT  JOB  STEP.  ♦/ 

/♦  THE  CALL  ON  SCAN  IS  THE  ONLY  STATEMENT  EXECUTED  IN  THE 
MAIN  PROGRAM.  IT  INITIATES  ALL  OTHER  ACTION  IN 
THE  FORM  OF  PROCEDURE  CALLS.  */ 

CALL  SCAN; 


I 

I 


/♦  THIS  PROGRAM  TAK 
PROCESSES  I 


THE 


FIRST 

THAT 


JOB  ST 
PROPER 


/***********  ****0**********04**0**»$***0tl***0*t‘****0*1i***tlt**/ 

GET_CARD; 

/*  HANDLES  ALL  INPUT  AND  OUTPUT  WHEN  WE  ABE  NOT  IN  A NESTING 
SITUATION.  REMOVES  SEQUENCE  NUMBERS  AND  ANYTHING  IN 
COLUMNS  73-80.  THEN  PADS  WITH  BLANKS.  V 


PROCEDURE; 


Oti  ENDFILE  (SYSIN)  CALL  CLEANUP; 

PUT  FILE(OUTPUT)  EDIT  (SUBSTB  (CA  RD  , 1 , 80)  ) (COL  { 1 ) , A (d  0)  ) ; 

GET  EDIT  (CARD)  (COL  (1)  , A (80)  ) ; 

PUT  EDIT  (CARD)  (COL  (1)  , A (80)  ) ; 

CARD  = • 'll  SUBSTH  (CARD, 7,66)  ||  BLANKS; 

END  GET_CARD; 

/^  *************************************************  **!********/ 

SCAN: 

/*  SCAN  IS  IN  PROGRESS  WHENEVER  THE  PHOGBAft  IS  NOT  IN  AN 
IF  NEST,  SCANS  FOR  IF  STATEMENTS,  CALLS  FOR 
PROCESSING  WHEN  FOUND.  ♦/ 

PROCEDURE; 

DO  WHILE  ('  1 »B)  ; 

IF  INDEX  (CARD,’  IF  ')>0  THEN 

IF  INDEX  (CARD, • THEN  ‘ ) >0  THEN 

CALL  PaOCESS_IF  (COUNT, 'THEN', *0'B)  ; 

ELSE  CALL  PROCESS_I F (COUNT ,' THEN 1 ' B) ; 

CALL  GET_CARD; 

END; 

END  SCAN; 

/************************************************************/ 

ERROR: 

/*  ERROR  PRINTS  OUT  AN  APPROPRIATE  ERROR  MESSAGE  AND 
TERMINATES  THE  PRE-PROCESSOR.  HERE  IS  WHERE  A 
METHOD  FOR  PREVENTING  FURTHER  JOB  STEPS  FROM 
EXECUTING  COULD  BE  PLACED.  */ 

PROCEDURE  (MESSAGE)  ; 

DECLARE  MESSAGE  CHARACTER  (80)  VARYING; 

PUT  FILE  (ERRORS)  EDIT  (ST ARS)  ( A (8 0)  ) ; 

PUT  SKIP  (2)  FILE(ERROBS)  EDIT  (MESS  AGE)  (COL  ( 1)  , A (80)  ) ; 

PUT  SKIP  (2)  FILE  (ERRORS)  EDIT  (STABS)  (A  (80)  ) ; 

CALL  CLEANUP; 

END  ERROR; 

^i**^**^*  **************************************  ***********^^^ 

CLEANUP:  /*  A CONVENIENT  PLACE  TO  STOP.  ♦/ 
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STOP; 

END  CLEANUP; 


PERIOD  PLACE: 


1 


/*  PROCEDURE  FINDS  THE  END  OF  A SENTENCE  OR  PARAGRAPH 

AND  PLACES  A PERIOD  THERE  OR  HEHOVES  IT  DEPENDING 
ON  PLACE-  ♦/ 

PROCEDURE (PLACE, STRINGS) ; 

DECLARE  STRINGS  CHAR ACTER  (6000)  VARYING; 

DECLARE  PLACE  BIT  (1)  ; 

DECLARE  (I,J,K)  FIXED  BINARY(15)  INITIAL(O); 

I = VERIFY (STRINGS, ' ')  ; 

/*  ALTERNATE  BETWEEN  FINDING  THE  NEXT  BLANK  AND  THE  NEXT 
NON-BLANK  UNTIL  ONLY  BLANKS  REMAIN.  V 

DO  WHILE  (I>0)  ; 

J = INDEX  (SUBSTR  (STRINGS, K)  , • ')  ♦ K; 

I = VERIFY (SUBSTR  (STRINGS, J)  , • •)  ; 

K = K >•  I; 

END; 

/*  CHECK  IF  THE  LAST  CHARACTER  IS  ALREADY  A PERIOD.  */ 

IF  PLACE  THEN  DO; 

IF  SUBSTR  (STRINGS,  J-2,  1) 'i= • THEN 
SUBSTR  (STRINGS, J-1,  1)  = 

END;  ELSE 

IF  SUBSTR  (STRINGS, J-2, 1) ' THEN 
SUBSTR  (STRINGS, J-2,  1)  = ' '; 

END  PERIOD_PLACE; 

yif  ***********************  **********/ 

PROCESS_IF; 

/*  THIS  PROCEDURE  WILL  PROCESS  THE  OUTER  MOST  NEST  OF  AN 
IF  STATEMENT.  V 

PROCEDUR  E (LAB£L_#, KEY_WORD,SET)  RECURSIVE; 

DECLARE  SET  BIT  (1)  ; 

/♦  SET,  DO  WE  KNOW  ALREADY  ITS  A STRUCTURED  IF?  ♦/ 

DECLARE  KEY.WORD  CHARACTER(6)  VARYING; 

/♦  KEY_WORD,  ARE  WE  AT  AN  ELSE  OH  AN  END-IF?  */ 


I 
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DECLARE  SEKIENCE  CHARACTER  (6000)  VARYING  INITIAL  ("); 

/*  STORAGE  FOR  CODE  */ 

DECLARE  (LABEL  f,TEMP  LABEL.#)  PICTURE  '994'; 

/*  STORAGE  FOR  DIFFERENT  LABEL  COUNTS.  */ 

/*  NEXT  LOOP  SCANS  FOR  EITHER  A THEN  OR  AN  ELSE. 

IF  THEN  IS  FOUND  THEN  WE  COULD  HAVE  A STRUCTURED 
IF  AND  PROCESSING  CONTINUES.  IF  AN  ELSE  IS  FOUND 
HE  DO  NOT  HAVE  A STRUCTURED  IF  AND  WE  RETURN.  •/ 


DO  WHILE  (SET)  ; 

CALL  GET.CARD; 

IF  INDEX(CARD,'  IF  • ) >0  6 INDEX  (CARD,’  THEN  • ) >0  THEN 
CALL  NEST.IF  (LABEL.#, *THEN>, SENTENCE, »0'fl)  ; 

IF  INDEX(CARD,'  THEN  • ) >0  THEN  SET='0'B; 

IF  (INDEX  (CARD,  • ELSE  • ) >0  J IN  DEX  (CARD  , • . •)>0) 

5 INDEX  (CARD,’  THEN  *)=0  THEN  DO; 

/*  NON-STRUCTURED  IF,  ALL  PERIODS  THAT  HAVE  JUST 

BEEN  PLACED  MUST  BE  REMOVED.  */ 

IF  INDEX  (CARD,  • ELSE  ')>0  6 I NDEX  (SENTENCE . *)>0  THEN 

CALL  PERIOD.PLACE (' O' B, SENTENCE) ; 

RETURN; 

END; 

END; 

I = INDEX  (CARD, KBY_HORD) -*-4; 

PUT  FILE(OUTPUT)  EDIT  (SUBSTR  (CARD,  1 , I)  ) (COL  ( 1)  , A (80)  ) ; 

SENTENCE  = SENTENCE  U • Z*  jj  LABEL.#  f|  FILLER; 

SENTENCE  = SENTENCE  ||  * • M SUBSTR (CARD , I , 68) ; 

TEMP.LABEL.#  = LABEL.#  ♦ 1; 

/*  WE  NOW  CAN  PLACE  A PERIOD  IF  WE  KNOW  WE  ABE 

COMPLETELY  OUT  OF  THE  NESTING.  */ 

IF  KEY.HORD= • ELSE*  THEN 
ENDING  = • . • ; 

ELSE 

ENDING  = • • ; 

CARD  = • PERFORM  Z*  | | LABEL.#  1 1 • THRU  Z* 

II  TEMP_LABEL_#  ||  ENDING; 

PUT  FILE  (OUTPUT)  EDIT  (C AR  D)  (COL  ( 1)  , A (8 0)  ) ; 

LABEL.#  = LABEL.#  ♦ 2; 

/♦  AT  THIS  POINT  ALL  IS  SET  UP  TO  NEST  THE  IF  SO  HE  CALL 

NEST_SCAN  TO  FIND  EITHER  ELSE,  END-IF,  OR  A PERIOD.  ♦/ 

CALL  NEST.SCAN  (K EY.HORD , LA BEL.# , SE NTENC E)  ; 

CALL  PERIOD.PLACE  (' 1 • B, SENTENCE)  ; 
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SENTENCE  = SENTENCE  1|  • Z*  ||  TE«P_LABEL_#  ||  FILLER; 

P'JT  FILE  (BOTTOM)  EDIT  (S ENTENCE)  { A)  ; 

SENTENCE  = • ' ; 

/♦  IF  WE  RETURNED  WITH  ELSE  WE  MUST  PROCESS  THE  FALSE  PART 
OF  THE  STRUCTURE,  OTHERWISE  WE  ARE  THROUGH,  ♦/ 

IF  KEI_WOHD=*ELSE'  THEN 

CALL  PROCESS_IF (LABEL_# , 'ELSE  • , »0'B)  ; 

END  PROCESS_IF; 

yi^^t************************»************^*****t*^***0^**t**«^ti/ 

NEST_SC AN: 

/♦  NEST  SCAN  STORES  ALL  CARD  IMAGES  UNTIL  IT  FINDS  A KEY 
WORD,  IT  THEN  RETURNS  WITH  THE  STORED  IMAGES.  */ 

PROCEDURE (WORD, COUNTER, LIST)  RECURSIVE; 

DECLARE  WORD  CHARACTER  (6)  VARYING; 

/*  RETURNS  WITH  KEY  WORD,  */ 

DECLARE  COUNTER  PICTURE  ’999* ; 

DECLARE  LIST  CHAR ACTER  (6000)  VARYING; 

ON  ENOFILE (SYSIN)  CALL  ER ROR ( • STR UC TUR E CLOSING  MISSING'); 

/*  SCAN  UNTIL  IF,  ELSE,  END-IF,  OR  A PERIOD  IS  FOUND.  V 

DO  WHILE  (•  1 • B)  ; 

GET  EDIT  (CARD)  (COL  (1)  , A (BO)  ) ; 

PUT  EDIT(CAHD)  (CO  L ( 1 ) , A (80)  ) ; 

CARD  = ' 'll  SUBSTR  (CARD,7,66)  |]  BLANKS; 

IF  INDEX  (CARD,*  ELSE  ')>0  THEN  DO; 

WORD  = 'ELSE* ; 

RETURN ; 

END ; 


I 
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/♦  IF  WE  FIND  AN  IF,  WE  START  NESTING,  */ 

IF  INDEX(CARD,'  IF  *)>0  THEN  DO; 

IF  INDEX(CARD,'  THEN  ')>0  THEN 

CALL  NEST_IF (COUNTER, ' T HEN ', LIST, • 0 ' B) ; 

ELSE  CALL  N EST_IF (COUNTER, • THE N ', LIST ,' 1 • B)  ; 
END ; 

/*  END-IF  MUST  BE  REMOVED,  PROCESSING  FOR  AN 
END-IF  OR  A PERIOD  IS  THE  SAME  SO  THE 


I 


45 


f SAME  KEY  WOBD  CAN  BE  HETURNED,  */ 

I = INDEX  (CARD,  ’ END-IF*)  ; 

J = INDEX  (CARD,  ' . • ) ; 

I IF  I>0  \ J>0  THEN  DO; 

» WORD  = • END-IF* ; 

IF  I>0  THEN 

j SUBSTH (CAHD,I,6)  = • »; 

I RETURN; 


/*  NO  KEY  WORDS  FOUND  SO  STORE  CARD  IMAGE.  ♦/ 

LIST  = LIST  I I CARD ; 

END; 

END  NE3T_SCAN; 

y>»«4i4c4[4t4t«4i4c4>«4<*4>t‘«>»4‘«******4‘*******»44**«****»**«**«»*«****«*/ 

NEST_IF: 

/♦  NEST_IF  IS  ALMOST  A COPY  OF  PROC£SS_IF  EXCEPT  INSTEAD 
OF  PRINTING  OUT  CARDS  IN  THE  STREAM  OF  THE  PROGRAM 
THEY  ARE  PUT  AT  THE  END  OF  THE  SOURCE  PROGRAM.  */ 

PROCEDURE  ( NUH BER, TYPE, LISTS, 3 ET1)  RECURSIVE; 

DECLARE  SET!  BIT  (1)  ; 

DECLARE  (NUMBER, NUM)  PICTURE  '999»; 

DECLARE  (LISTS, TEMP)  CHARACTER  (6000)  VARYING; 

DECLARE  TYPE  CHARACTER  (6)  VARYING; 

DECLARE  STRING  CHARACTER  (80)  VARYING  INITIAL(’*); 

DECLARE  POINTER  FIXED  BINARY(15); 

POINTER  = LENGTH  (LISTS)  ; 

DO  WHILE  (SET1)  ; 

LISTS  = LISTS  II  SUBSTH  (CARD,  1 ,80)  ; 

GET  EDIT(CARD)  (CO  L ( 1 ) , A (80 ) ) ; 

PUT  EDIT  (CARD)  (COL  (1)  , A (80)  ) ; 

CARD  = • 'll  SUBSTH  (CARD, 7, 66)  I1  BLANKS; 

IF  INDEX  (CARD,'  IF  ' ) >0  & INDEX  (CARD,'  THEN  *)>0  THEN 
CALL  NEST_IF (NUMBER, 'THEN' , LISTS, 'O'B) ; 

IF  INDEX(CARD,'  THEN  ' ) >0  THEN  SET1='0'B; 

IF  (INDEX  (CARD,  ' ELSE  ' ) >0  I INDEX  (CARD,  ' . ')>0) 

S INDEX  (CARD,'  THEN  ')=0  THEN  DO; 

I = INDEX (SUBSTR  (LISTS, PUI NTER)  , '-  '); 

DO  WHILE  (I>0)  ; 

SUBSTR  (LISTS, I + POINTER- 1,  1)  = ' 

I = INDEX (SUBSTR (LISTS, POINTER) ,*.  '); 

END; 


I 
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i RETURN; 

END  ; 

END; 

f NUrt  = NUHdEB  ♦ 1; 

I = INDEX  (CARD,  TYPE)  +4  ; 

I LISTS  = LISTS  II  SUBSTK (SUBSTH (CARD,  1 , I)  M BLANKS, 1, dO)  ; 

TEA?  = • Z'  II  NUMBER  ||  FILLER; 

TEMP  = TEMP  II  SUBSTR(CAR0,I,80)  ; 

I IF  INDEX  (CARD,  • . *)>0  I TYPE='ELSE*  THEN 

‘ ENDING  = ELSE  ENDING  = ’ 

STRING  = • PERFORM  Z'  |J  NUMBER  1|  ' THRU  Z* 

J I NUH  I I ENDING  | | BLANKS; 

LISTS  = LISTS  II  STRING; 

NUMBER  = NUMBER  ♦ 2; 

CALL  NEST_SCAN  (TY  PE,  NUMBER,  TEMP)  ; 

CALL  PERIOD_PLACE (' 1 *B,TEMP) ; 

TEMP  = TEMP  II  ’ Z*  I I NUM  ||  FILLER; 

PUT  FILE(BOTTOM)  ED  IT  (T  EM  P)  (A)  ; 

IF  TYPE=’ELSE*  THEN  DO; 

CALL  NEST_IF  (N UMB ER , • ELSE • , LISTS, • 0*  B)  ; 

END ; 

I CALL  P£RIOD_PLACE (• 1 *B, LISTS)  ; 

END  NEST_IF; 

I END  MAIN; 

i 

I 


I 


I 


I 


I 
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/*  THIS  SECOND  JOB  STEP  TAKES  THE  OUTPUT  FBOM  THE  PREVIOUS 
STEP  WITH  ALL  NESTED  IP'S  PROCESSED  AND  PROCESSES  IT 
FOR  IN-LINE  PERFORMS,  V 

MAIN: 

PROCEDURE  OPTIONS  (MAIN)  REORDER; 

DECLARE  (CARD, NEW_CARD)  CHA RACT E R ( 80)  VARYING  IN ITI AL ( (8 0)  • '); 
/*  CARD  IMAGE  STORAGE  */ 

DECLARE  (COUNT, COUNT_PLUS)  PICTURE  '999'  I NITI AL  ( 100)  ; 

/*  LABEL  COUNT  STORAGE  ♦/ 

DECLARE  NEXT_WOHD  CH AR ACTER (4 0)  VARYING; 

DECLARE  CASE_LABEL  CHARACTER (40)  VARYING; 

DECLARE  CASE_NUMBER  PICTURE  *9*  INITIAL  (1); 

DECLARE  STARS  CHAR ACTER  (80)  I NI TI A L ( (8 0)  • * • ) ; 

DECLARE  RESERVED(30)  C HARACTER  ( 1 0)  VARYING  INITIAL 

(•  ACCEPT  ADD  ALTER  APPLY  CALL  *,*  CANCEL  *, 

• CLOSE', • COMPUTE  COPY  DISPLAY  DIVIDE  ', 

• ENTER  ENTRY  EXAMINE  GO  GOBACK  IF  ', 

• MOVE  MULTIPLY  OPEN  PERFORM  READ  ', 

• REWRITE  SEEK  START  STOP  SUBTRACT  ', 

' TRANSFORM  USE  WRITE  '); 


OPEN  FILE  (ERRORS)  PRINT; 

CALL  FIND_PROCEDURE_DIVISION; 

CALL  SCAN? 

^^^L^^^^*^Ht^^4***********>^**************  **************************/ 

GET_CARD: 

/*  HANDLES  ALL  CARD  IMAGES  WHEN  NOT  IN  NESTING  SITUATION.  ♦/ 
PROCEDURE ; 

PUT  FILE(OUT)  EDIT  (CARD)  (COL  (1)  , A (80)  ) ; 

GET  EDIT  (CARD)  (COL  ( 1 ) , A (80)  ) ; 

PUT  EDIT  (CARD)  (COL  (1)  , A (80)  ) ; 

END  GET_CARD; 

/«**#«*««*  ^O**********:**^*****!**  *««*«<  «***«*«»*«***«<  *»«****4>*»«*/ 

FIND  PROCEDURE  DIVISION; 


/*  THIS  PROCEDURE  SCANS  FOB  THE  WORKING  SIOHACE  SECTION 
IF  IT  DOBS  NOT  FIND  ONE  IT  HAKES  ONE, 

IN  EITHER  CASE  IT  ADDS  THE  RESERVED  WORD  CASE 


I 
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FOR  THE  PROCESSING  OF  CASE  STATEMENTS.  */ 

PROCEDURE; 

DECLARE  (1,J)  BIT(1)  IN  IT  I AL  ( ' 1 • B)  ; 

DECLARE  K PICTURE  '9‘  ; 

DO  WHILE  (INDEX  (CARD,  ' PROCEDURE  DI VI SIO N- • ) = 0)  ; 

CALL  GET_CARD; 

/*  IF  THE  PROCEDURE  DIVISION  IS  FOUND  FIRST,  THEN  A WORKING 
STORAGE  SECTION  MUST  BE  ADDED.  */ 

IF  INDEX (CARD, • PROCEDURE  DIVISION. •) >0  THEN  DO; 

IF  I THEN  DO; 

PUT  FILE  (OUT)  EDIT(»  WORKING-STORAGE  SECTION.*) 

(COL  (1)  ,A  (80)  ) ; 

DO  K=1  ro  9; 

PUT  FILE  (OUT)  EDIT{*  77  CASE*  |J  K |( 

• PICTURE  9 (4)  . • ) (COL  (1)  ,A  (80)  ) ; 

END ; 

I = • 0 • B ; 

J = ' O'B; 

END;  ELSE  J = *0'B; 

END; 

/*  IF  WORKING  STORAGE  IS  FOUND  FIRST  NEED  ONLY  TO  ADD  CASE.  */ 
IF  INDEX (CARD, * WORKING-STORAGE  • ) >0  THEN  DO; 

PUT  FILE  (OUT)  EDIT  (CARD)  (COL(1)  ,A  (80)  ) ; 

DO  K=1  TO  8; 

PUT  FILE  (OUT)  EDITC  77  CASE*  |1  K J) 

• PICTURE  9(4)  . •)  (COL  (1)  ,A  (80)  ) ; 

END; 

CARD  = • 77  CASE9  PICTURE  9(4).'; 

I = 'O'B; 

END; 

END; 

END  FIND_PROCEDURE_DIVISICN ; 


PROCEDURE; 

/*  EVERYTHING  STARTS  WITH  A PERFORM.  */ 

ON  ENDFILE  (SYSIN)  CALL  CLEANUP; 

DO  WHILE  (•  1 * B)  ; 

IF  INDEX  (CARD, 'PERFORM')  >0  THEN 

CALL  PROCESS_PERFORM (COUNT, CASE  NUMBER); 
CASE_NUMBER  =1; 


1 


i. 


r 


I 


I 
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CALL  UET_CARD; 

END; 

END  SCAN; 

40  00  40  4 0 0 00  00*  0 000  0 00  0 0*0  000i0t  0 0000  00  *00*0/ 

NEST_SCAN: 

/•  ONCE  HE  ARE  IN  A PERFORM  PARAGRAPH  SEARCH  FOR  AN 

END-PERFORM  OR  A NESTED  PERFORM.  */ 

PROCEDURE  (K£Y_HORD)  RECURSIVE; 

ON  ENDFILE  (SYSIN)  CALL  ERROR (» STRUCTURE  CLOSING  MISSING'); 

DO  HHILE  (•  1 'B)  ; 

IF  INDEX  (CARD, 'PERFORM')  >0  THEN  DO; 

COUNT  = COUNT  + 1; 

CALL  PROCESS_PERFOHM (COUNT, CASE_NUMBER)  ; 

END; 

IF  INDEX (CARD, 'END-PERFORM') >0  THEN  DO; 

KEY_WOBD  = 1; 

RETURN ; 

END; 

CALL  G£T_CARD; 


END; 

END  NEST_SCAN; 

^00000000000000000000000000000000000000000000000000000000000000/ 

FIND_HORD; 

/*  SEARCHES  FOR  NEXT  WORD  IN  CARD  AND  RETURNS  IT. 

CHANGES  NEH_CARD  TO  THE  REMAINDER  OF  CARD.  */ 

PROCEDURE (WORD) ; 

DECLARE  HORD  CHAR ACTER  (40)  VARYING; 

NEW  CARD  = SUBSTF (CARD, INDEX  (CARD , HORD) ) ; 

NEh'cARD  = SUBSrR(NEH  CARD, INDEX ( NEH_CAHD, ' ')); 

NEh'cARD  = SUBSTR  (NEH~CARD, VERIFY  (NEH_CARD, ' ')); 

NEXT  HORD  = SU  B3  T R (NEH_C  AHD,  1 , IND  EX  (N  EH_C  ARD  , ' ')-!); 


END; 


IL 


ERRUH: 

PROCEDURE  (MESSAGE)  ; 

DECLARE  MESSAGE  CHARACTER  (80)  VARYING; 

PUT  FILE  (ERRORS)  EDIT (STARS)  (A (80)  ) ; 

PUTSKIP{2)  FILE(ERRORS)  EDIT  (MESS  AGE)  (COL  (1 ),  A (80)  ) ; 

PUT  SKIP(2)  FILE(ERRORS)  EDIT  (ST ARS)  (A  (80)  ) ; 

CALL  CLEANUP; 

END  ERROR; 

^^Witi^0^>tf^^^i^if4************************4*********V******  *********/ 

CLEANUP: 

PROCEDURE; 

STOP ; 

END  CLEANUP; 

y^iif**^^nf^*t4************^*************^4*********************m*/ 

CONDITIONAL_SCAN: 

PROCEDURE; 

ON  ENDFILE  (SYSIN)  CALL  EH  RO  R ( » 1 .1  PROPER  CONDITIONAL'); 

DO  WHILE ( ' 1 ' B) ; 

IF  INDEX  (NEW_CARDH  * '/'•  ')>0  THEN  RETURN; 

DO  1=1  TO  30; 

IF  INDEX (NEM_CARD, RESERVED  (I) ) >0  THEN  RETURN; 

END  ; 

CALL  GET_CARD; 

N£«_CARD~=  CARD; 

END; 

END  CONDITION AL_SCAN; 

^0^f:ti:^^,^i^^t^**tt^t***************  *************  ******************/ 

PHOCESS_?ERFORM: 

/*  WHEN  PROCESSING  THE  PERFORM,  WE  TREAT  BEFORE  AND  CASE 
DIFFERENTLY  THEN  OTHER  IN  LINE  PERFORMS  AND  DO 
NOTHING  WITH  OUT  OF  LINE  PERFORMS.  */ 

PROCEDURE  (COUNT,CASE_NUMBER)  RECURSIVE; 

DECLARE  (COUNT, TEMP)  PICTURE  *999'; 

DECLARE  (CASE_NUM3EH,0LD_CASE)  PICTURE  '9'; 

DECLARE  KEY_WOHD  FIXED  BINARY  (15)  INLTIAL(O); 


1 


61 


CALL  FEND_WOaO {• PERFORM* ) ; 

COUMT_PLUS  = COUNT  *■  1; 

/♦  BEFORE — PERFORM  ONCE  AND  THEN  CHANCE  TO  AN  UNTIL.  ♦/ 
IF  NEXT_WORD=*BEFORE'  THEN  DO; 

SUBSTR  (NEW_CARD,  INDEX  (NEH_CARD,  • BEFORE* ) ,6)  = 'UNTIL  •; 

PUT  FILE(OUT)  EDIT(*  PERFORM  Z*  H COUNT  M 

* THRU  Z*  H COUNI_PLUS  ||  *.* 

) (COL  (1)  ,A  (80)  ) ; 

NEXT_MOBD  = * UNTIL*; 

END; 

/*  CHANCE  THE  IN  LINE  PERFORM  TO  AN  OUT  OF  LINE  ONE.  ♦/ 
IF  NEXT_WORD=*UNTIL*  | NEXT_WORD=* VARYINC * THEN  DO; 

PUT  FILE  (OUT)  EDIT(*  PERFORM  Z*  )]  COUNT  || 

• THRU  Z*  j]  COUNT_PLUS  ||  * * |J 

NEii(_CARD)  (COL  (1)  , A (80)  ) ; 

CARD  = * * ; 

/*  SCAN  TO  FIND  THE  END  OF  THE  CONDITIONAL.  V 

IF  INDEX (NEW_CARD| I • *,*.  *)=0  THEN 
CALL  CONDITIONAL_SCAN ; 

PUT  FILE (OUT)  EDIT  ( * 

'.  *)  (COL  (1)  ,A  (80)  ) ; 

PUT  FILE(OUT)  EDITC  Z* 

(COL  (1)  ,A  (80)  ) ; 

COUNT  = COUNT  ♦ 1; 

TEMP  = COUNT; 

CALL  NEST_SCAN (KEY_WORD) ; 

IF  KEY_HORD=1  THEN  DO; 

PUT  FILE(OUT)  EDIT(*  GO  TO  Z*  |1  TEMP  || 

*.  *)  (COL(1)  ,A(80))  ; 

CARD  = * Z*  I I TEMPI  | *.  •; 

END;  ELSE 

CALL  ERROR (* IMPROPER  STRUCTURE  CLOSING*); 

COUNT  = COUNT  ♦ 1 ; 

KEY_WORD  = 0; 

END; 

IF  NEXT_RORD='CASE*  THEN  DO; 

/*  ISOLATE  THE  CASE  LABEL,  ASSIGN  TARGET  TO  CASE.  ♦/ 

CALL  FIND  WORD  (• CASE* ) ; 

I = INDEx1nEW_CARD, * (* ) ; 

CASE_LABEL  = SUBSTR  (NEH_CARD,  1,1-1)  ; 

PUT  FILE  (OUT)  EDITC  ~ COMPUTE  CASE*  |1 

CASE_NUMBEH  II  * = * II 

SUBSTR  (NEW_CARD,  I,  INDEX  (NEW_CABD,  *)  *)-I»1) 


GO  TO  Z’  ))  COUNT_PLUS  )| 
I I COUNT  II  *,  * ) 
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II  '.  •)  (COL  (1)  , A (80)  ) ; 

OLD_CASE  = CA3E_NUMBER; 

CAsi_NUMBER  = CASE_NUMBEB  ♦ 1; 

CARD  = • GO  TO  Z'll  CCUNI  ||','; 

COUNT  = COUNT  ♦ 1; 


CALL  CASE_SCAN  (OLD_CASE)  ; 


END; 

CALL  PROCESS  TIMES; 

CALL  PR0CES3~BEF0RE; 

END  PROCESS_PERFORM; 

y^n^t^tti^^^^lHit********************************^*  ¥******  *********/ 

PROCESS_BEFORE: 

/*  PBOCESS_BEFORE  LOOKS  FOR  NON  STRUCTURED  BEFORES 
AND  THEN  PROCESSES  THEM  IF  FOUND  V 

PROCEDURE; 

DO  WHILE  {•  1 ' B)  ; 

I = IND£X(CARD,'  BEFORE  •); 

IF  I>0  THEN  DO; 

PUT  FILE(OUT)  EDIT  (SUBSTR  (CARD,  1,1)  ) (COL  (1)  ,A  (80)  ) ; 
SUBSTR  (CARD,I,8)  = • UNTIL  •; 

3UB3TR  (CARD,  1,  INDEX  (CARD,  *PERFORM')-1)  = ' *; 

RETURN; 

END ; 

IF  INDEX  (NEW_CARD| I • *)>0  THEN  RETURN; 

DO  1=1  ro  30; 

IF  INDEX (NEW_CARD, RESERVED  (I) ) >0  THEN  RETURN; 

END  ; 

CALL  GET_CARD; 

NEH_CARD  = CARD; 

END; 


END  PROCESS_BEFORE; 
PROCESS  TIMES: 


/*  PR0CESS_T1MES  LOOKS  FOR  STRUCTURED  TIMES 

AND  THEN  PROCESSES  THEM  IF  FOUND  ♦/ 

PROCEDURE; 

CALL  FIND_HORD (NEXT_HOHD)  ; 

IF  NEXT_WORD=»TIMES ' THEN  DO; 
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CALL  fIND_WORD(*  PERFORM  •); 

PUT  FILE  (OUT)  EDITC  PERFORM  Z*  ||  COUNT  I1 

• THRU  Z*  II  COUNT  PLUS  ||  ' * 11 

NEM_CARD)  (COL  (1)  , a7«0)  ) ; 

CARD  = • • ; ~ 

PUT  FILE  (OUT)  EDITC  GO  TO  Z*  1|  COUNT  PLUS 

II  '.  •)  (COL  (1)  ,A  (80)  ) ; 

PUT  FILE(OUT)  EDITC  Z*  |J  COUNT  ||  *.*) 

(COL  (1)  ,A  (80)  ) ; 

COUNT  = COUNT  ♦ 1; 

TEMP  = COUNT; 

CALL  NEST_SCAN (KEY_HOHD)  ; 

IF  KEY_HORD=1  THEN  DO; 

PUT  FILE  (OUT)  EDIT(»  GO  TO  Z ' || 

TEMP  II  '.  •)  (COL  (1)  , A (80)  ) ; 

CARO  = • Z*  I I TEMP  II  ; 

END;  ELSE 

CALL  ERROR  C IMPROPER  STRUCTURE  CLOSING')'. 

COUNT  = COUNT  + 1; 

KEY_WOHD  = 0; 

END; 

END  PR0CES3_TIMES; 


CASE_SC AN: 

/*  BEING  PASSED  THE  CASE  LABEL  WE  SCAN  FIXING  LABELS  AS  ME 
FIND  THEM  UNTIL  FINDING  END-PEHFORM.  THE  GO  TO 
DEPENDING  ON  IS  THEN  SET  UP.  */ 

PROCEDURE (OLD_CASE) ; 

DECLARE  OLD_CASE  PICTURE  '9*; 

DECLARE  (CASE_PIC,CASE_COUNT)  PICTURE  '999'; 

CASE_COUNT  = 1 ; 

CALL  GET_CARD; 

DO  WHILE  (INDEX  (CARD, ' E ND-PERPORM • ) =0)  ; 

IF  INDEX (CARD, CASE_LABEL) >0  THEN  DO; 

PUT  FILE(OUT)  EDITC  GO  TO  Z ' ||  COUNT  ||  ’.') 

(COL  (1)  ,A  (80)  ) ; 

CARD=  ' ’ll  CASE_LABEL  |)  ||  CASE_COUNT 

II  • II  SUBSTH (CARD, INDEX  (CARD, •)') ♦Z)  ; 
CASE_COUNT  = CASE_COUNT  ♦ 1; 

END;  ” 

IF  INDEX (CARD, ' PERFORM  • ) >0  THEN 

CALL  PROCESS_PERFORM (COUNT, CASE_NUMBER)  ; 

CALL  GET_CAHD; 

END; 
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PUT  FILE  (OUT)  BDITC  GO  TO  Z • |]  COUNT  1] 

(COL  (1)  ,A (80) ) ; 

COUNT_PLUS  = COUNT  - 1; 

PUT  FILE  (OUT)  EDITC  Z*  It  COUNT_PLUS  ||  '.•) 

(COL  (1)  ,A  (80)  ) ; 

PUT  FILE  (OUT)  EDITC  GO  TO')  (COL  (1 ) , A (BO)  ) ; 

DO  CASE_PIC  = 1 TO  CASE_COUNT-1 ; ; 

PUT  FILE  (OUT)  EDIT{'~  ' II  CASE_LABEL  1| 

)JCASE_PIC  II  • , •)  (COL  (1)  ,A  (80)  ) ; 

END; 

PUT  FILE  (OUT)  EDITC  DEPENDING  ON  CASE* 

II  OLD_CASE  II  *.  •)  (COL  (1)  ,A  (80)  ) ; 

CARD  = * Z*  I J COUNT  | | 

COUNT  = COUNT  ♦ 1; 

END  CASE_SCAN; 

END  MAIN; 
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IDENTIFICAriON  DIVISION. 

PHOGHAM-ID.  PROG6. 

AUTHOR.  BOB  HILB. 

INSTALLATION.  AIJ  COMPUTER  CENTER. 

DATE-HRITTEN.  NOV  2J,1975. 

DATE-COMPILED. 

REMARKS. 

ENVIRONMENT  DIVISION. 

CONFIGURATION  SECTION. 

SOURCE-COMPUTER.  IBM-370-155. 

OBJECT-COMPUTER.  IBM-370- 155. 

INPUT-OUTPUT  SECTION. 

FILE-CONTROL. 

SELECT  STRANGE-FILE  ASSIGN  TO  UT- S-STH ANG E. 
SELECT  PRINT-FILE  ASSIGN  TO  UT-S-PRINTER. 
DATA  DIVISION. 

FILE  SECTION. 

FD  STRANGE-FILE 

RECORD  CONTAINS  80  CHARACTERS 
BLOCK  CONTAINS  10  RECORDS 
RECORDING  MODE  IS  F 
LABEL  RECORDS  ARE  STANDARD 
DATA  RECORD  IS  STRANGE-RECORD. 

01  STRANGE-RECORD. 


02 

RECORD-TYPE 

PICTURE  9. 

02 

SUBSCRIPTS. 

03 

ROW 

PICTURE  9(5)  USAGE  IS  COMPUTATIONAL. 

03 

COLUMNS 

PICTURE  9(5)  USAGE  IS  COMPUTATIONAL. 

02 

TYPE 

-CNE-RECORD. 

03 

VALUE-1 

PICTURE  9(5)  USAGE  IS  COMPUTATIONAL. 

03 

FILLER 

PICTURE  X (67) . 

02 

TYPE 

-TWO-RECORD 

REDEFINES  TYPE-ONE-RECORD. 

03 

VALUE-2 

USAGE  IS  COMPUTATIONAL- 1. 

03 

FILLER 

PICTURE  X(67). 

02 

TYPE 

-THREE-RECORD 

REDEFINES  TYPE-ONE-RECORD. 

03 

VALUE-3 

USAGE  IS  COMPUTATIONAL-2. 

03 

FILLER 

PICTURE  X(63). 

02 

TYPE 

-FOUR-RECORD 

REDEFINES  I YPE-ONE-RECORO. 

03 

VALUE-4 

PICTURE  9(5)  USAGE  IS  COMPUTATIONAL-!. 

03 

FILLER 

PICTURE  X(68). 

PRINT-FILE 

RECORD  CONTAINS  132  CHARACTERS 
BLOCK  CONTAINS  1 RECORDS 
RECORDING  MODE  IS  F 
LABEL  RECORDS  ARE  STANDARD 
DATA  RECORD  IS  PRINT-LINE. 

01  PRINT-LINE  PICTURE  X(132). 

WORKING-STORAGE  SECTION. 


77 

MEAN 

PICTURE 

9 (6)  V9  (6) 

VALUE 

ZEROS. 

77 

SUMS 

PICTURE 

9 (6)  V9(6) 

VALUE 

ZEROS. 

77 

SUM-OF-SgUARES 

PICTURE 

9(6)  V9  (6) 

VALUE 

ZEROS. 

77 

VARIANCE 

PICTURE 

9 (6)  V9(6) 

VALUE 

ZEROS. 

57 


77 

77 

77 

77 

01 


01 


STANDARD-DEVIATION 

PICTURE  9{6)V9(6)  VALUE  ZEROS- 

I 

PICTURE  9 (6)  . 

J 

PICTURE  9 (6) . 

K 

PICTURE  9(3). 

STRANGE-MATRIX. 
02  STRANGE-ROW 

OCCURS  10  TIMES. 

03  STR ANGE-COLUMN 

OCCURS  10  TIMES. 

04  STRANGE-ARRAY 

USAGE  IS  COMPUTATIONAL-2. 

PRINT-FORMAT. 

02  FILLER 
02  PRINT-LEADER 
02  FILLER 
02  PRINT-MEAN 
02  FILLER 
02  FILLER 
02  PRINT-VARIANCE 
02  FILLER 
02  FILLER 

VALUE  'STANDARD  DEVIATION=', 

02  PRINT-STANDARD-DEVIATICN  PICTURE  Z(6).9(6). 


PICTURE 

X 

VALUE 

SPACES, 

PICTURE 

X (40) 

VALUE 

SPACES. 

PICTURE 

X (7) 

VALUE 

•MEAN=*. 

PICTURE 

Z(6)  . 

9(6)  . 

PICTURE 

X(3) 

VALUE 

f 1 

t • 

PICTURE 

X (15) 

VALUE 

• VARIANCE^* 

PICTURE 

Z(6)  . 

9(6)  . 

PICTURE 

X (3) 

VALUE 

f 1 

# • 

PICTURE 

X(24) 

PROCEDURE  DIVISION. 

A SECTION. 

A1 OO-OPEN-FILES. 

OPEN  INPUT  STRANGE-FILE 
OUTPUT  PRINT-FILE. 

A1 10-IN ITIALIZE- ARRAY. 

PERFORM  A300-ZERO-ARH AY  THRU  A300-EXIT 

VARYING  I FROM  1 BY  1 UNTIL  I E^iUAL  11 
AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

A 120-RE AD- STRANGE- FILE. 

READ  STRANGE-FILE  AT  END  GO  TO  A 1 40-COM PUTE-ME A N . 

A1 30-CREATE-ARR AY. 

IF  RECORD-TYPE  EQUAL  'I* 

PERFORM  A310-TYPE- 1-MOVE  THRU 
IF  RECORD-TYPE  EQUAL  '2' 

PERFORM  A320-TYPE-2-MOVE  THRU 
IF  RECORD-TYPE  EQUAL  *3* 

PERFORM  A330-TYPE-3-MOVE  THRU 
IF  RECORD-TYPE  EQUAL  'U' 

PERFORM  A340-TYPE-4-MOVE  THRU 


A310-EXIT. 

A320-EXIT. 

A330-EX1T. 

A340-EX1T. 


GO  TO  A 120-HEAD-STRANGE-FILE. 

A1 40-COMPUTE-MEAN. 

PERFORM  A350-SUM  THRU  A350-EXIT 

VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 

AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

DIVIDE  SUMS  BY  100  GIVING  MEAN  ROUNDED. 

A 150- VARIANCE- STANDARD- DEVI ATE, 

PERFORM  A360-SUM-OF-SQUARES  THRU  A360-EXIT 
VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 

AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

COMPUTE  VARIANCE  = (SUM-OF-SQUARES  - SUMS  •*  2)  / 9900- 
COMPUTE  STANDARD-DEVIATION  = VARIANCE  **  .5. 
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ilOVE  MEAN  TO  PHINT-MEAN. 

MOVE  VARIANCE  TO  PRINT-V ARIANCE. 

MOVE  STANDARD-DEVIATION  TO  PHI NT-STAN D AHD-DE V lATION. 

MOVE  THE  VALUES  FOR  THE  ORIGINAL  ARRAY  ARE*  TO  PRIN  T- LEA  DER . 
WRITE  PRINT-LINE  FROM  PRINT-FORMAT 
AFTER  POSITIONING  1 LINES. 

A165-TEST. 

PERFORM  A170-COMPUTE-2ND-MEAN  BEFORE  I EQUAL  1. 


PERFORM  BEFORE  I EQUAL  1. 


PERFORM  UNTIL  I IS  GREATER  THAN  J. 

IF  I EQUAL  11  THEN 

COMPUTE  I = 1 

ELSE 

IF  J EQUAL  11  THEN 

COMPUTE  J = 20 
IF  K EQUAL  1 

COMPUTE  K = 2 
ELSE  NEXT  SENTENCE 

ELSE 

IF  K EQUAL  5 THEN 
COMPUTE  J = 6 
END-IF 

COMPUTE  J = 21 


PERFORM  CASE  LABELA(K) 

LABELA(I)  COMPUTE  I = 99 
LABELA (2) 

COMPUTE  I = 98 

END-PERFORH 


END-IF 

COMPUTE  J = 22 


PERFORM  VARYING  I FROM  1 BY  1 
UNTIL  I EQUAL  11 
COMPUTE  J = 97 
END-PERFORM 


END-IF 


END-PERFORM. 


PERFORM  CASE  LABEL(K). 
LABEL  (1)  . 

COMPUTE  1=1- 
LABEL  (2) . 
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COMPUTE  I = 12. 
END-PERFORM, 

END-PERFORM. 


A170-COMPUTE-2ND-MEAN. 

MOVE  ZEROS  TO  SUMS. 

PERFORM  A350-SUM  THRU  A350-EXIT 

VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 

AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

DIVIDE  SUMS  BY  100  GIVING  MEAN  ROUNDED, 
A180-2ND-VAR-SrANDARD-DEV I ATE. 

MOVE  ZEROS  TO  SUM-OF-SQUARES. 

PERFORM  A3bO-SUrt-OF-3QUARES  THRU  A360-EXIT 
VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 

AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

COMPUTE  VARIANCE  = (SUM-OF-SQUARES  - SUMS  *♦  2)  / 9900. 
COMPUTE  STANDARD-DEVIATION  = VARIANCE  *♦  .5. 

MOVE  MEAN  TO  PRINT-MEAN, 

MOVE  VARIANCE  TO  PRINT- VARIANCE. 

MOVE  STANDARD-DEVIATION  TO  PRINT- STAN DARD-DEVIATION. 

MOVE  'THE  VALUES  OF  THE  CONVERTED  ARRAY  ARE*  TO  PRINT-LEADER. 
WHITE  PRINT-LINE  FROM  PRINT-FORMAT 
AFTER  POSITIONING  2 LINES. 

A1 90-CLOSE-FILES. 

CLOSE  STRANGE-FILE 
PRINT-FILE. 

STOP  RUN, 

A300-ZERO-ARRAY. 

COMPUTE  STRANGE-ARRAY  (I,  J)  = 0. 

A300-EXIT. 

EXIT, 

A310-TYPE-1-MOVE. 

MOVE  VALUE- 1 TO  STRANGE-ARRAY  (ROW,  COLUMNS). 

A310-EXIT. 

EXIT- 

A320-TYPE-2-MOVE. 

MOVE  VALUE-2  TO  STRANGE-ARRAY  (ROW,  COLUMNS). 

A320-EXIT. 

EXIT. 

A330-TYPE-3-MOVE. 

MOVE  VALUE-3  TO  STRANGE-ARRAY  (ROW,  COLUMNS). 

A330-EXIT. 

EXIT. 


A340-TYPE-4-MOVE. 

MOVE  VALUE-4  TO  STRANGE-ARRAY 
A340-EXIT. 

EXIT. 

A350-3UM. 

ADD  STRANGE-ARRAY  (1, 


(HOW,  COLUMNS). 


J)  TO  SUMS 


APPENDIX  C 
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IDENTIFICATION  DIVISION. 

PaOGRAM-ID.  PROG6. 

AUTriOR.  80B  HILB. 

INSTALLATION.  AU  COMPUTER  CENTER. 

DATE-WRITTEN.  NOV  23,1975. 

DATE-COMPILED. 

REMARKS. 

ENVIRONMENT  DIVISION. 

CONFIGURATION  SECTION. 

SOURCE-COMPUTER . IBM-370- 155. 

OBJECT-COMPUTER.  IBM-370-155. 

INPUT-OUTPUT  SECTION. 

FILE-CONTROL. 

SELECT  STRANGE-FILE  ASSIGN  TO  UI-S-STRANGE. 
SELECT  PRINT-FILE  ASSIGN  TO  U T- S- PR IN T ER. 
DATA  DIVISION. 

FILE  SECTION. 

FD  STRANGE-FILE 

RECORD  CONTAINS  80  CHARACTERS 
BLOCK  CONTAINS  10  RECORDS 
RECORDING  MODE  IS  F 
LABEL  RECORDS  ARE  STANDARD 
DATA  RECORD  IS  STRANG E- RECORD. 

01  STRANGE-RECORD. 


02 

RECORD-TYPE 

PICTURE  9. 

02 

SUBSCRIPTS. 

03 

ROW 

PICTURE  9(5)  USAGE  IS  COMPUTATIONAL, 

03 

COLUMNS 

PICTURE  9(5)  USAGE  IS  COMPUT ATIONAL. 

02 

TYPE 

-CNE-RECORD. 

03 

VALUE-1 

PICTURE  9(5)  USAGE  IS  COMPUT  ATIONAL. 

03 

FILLER 

PICTURE  X(67). 

02 

TYPE 

-TWO-RECORD 

REDEFINES  TYPE-CNE-RECORD. 

03 

VALUE-2 

USAGE  IS  COMPUTATIONAL- 1. 

03 

FILLER 

PICTURE  X(67). 

02 

TYPE 

-THREE-RECORD 

REDEFINES  T YPE-ONE-BECORD. 

03 

VALUE- 3 

OSAGE  IS  COHPUTATICNAL-2. 

03 

FILLER 

PICTURE  X(63). 

02 

TYPE 

-FOUR-RECORD 

REDEFINES  TYPE-ONE- RECORD. 

03 

VALUE-U 

PICTURE  9(5)  USAGE  IS  COMPUTATIONAL 

03 

FILLER 

PICTURE  X(b8). 

PRINT-FILE 

RECORD  CONTAINS  132  CHARACTERS 
BLOCK  CONTAINS  1 RECORDS 
RECORDING  MODE  IS  F 
LABEL  RECORDS  ARE  STANDARD 


DATA  RECORD 

IS  PRINT- 

LINE. 

01 

PRINT-LINE 

PICTURE  X (132) . 

WORK 

ING-STORAGE 

SECTION. 

77 

CASE1 

PICTURE 

9(4)  . 

77 

CASE2 

PICTURE 

9(4). 
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I 


\ 

t 

I 

f 

I 

» 
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CASE3  PICTURE 

9(4). 

77 

CA3E4  PICTURE 

9(4)  . 

77 

CASE5  PICTURE 

9(4)  . 

77 

CASE6  PICTURE 

9(4). 

7 7 

CASE7  PICTURE 

9 (4)  . 

77 

CASE8  PICTURE 

9(4)  . 

77 

CA3E9  PICTURE 

9(4)  . 

77 

MEAN 

PICTURE 

9 (6)  V9  (6)  VALUE  ZEROS. 

77 

SUMS 

PICTURE 

9 (6)  V9  (6)  VALUE  ZEROS. 

77 

SUM- 

OF-SQUARES 

PICTURE 

9 (6) V9  (6)  VALUE  ZEROS. 

77 

VARIANCE 

PICTURE 

9 (6)  V9  (6)  VALUE  ZEROS. 

77 

STANDARD-DEVIATION 

PICTURE 

9 (6) V9  (6)  VALUE  ZEROS. 

77 

I 

PICTURE 

9(6)  . 

77 

J 

PICTURE 

9(6). 

77 

K 

PICTURE 

9(3)  . 

01 

STH ANGE-MATRIX. 

02 

STR ANGE-RON 

OCCURS 

10  TIMES. 

03  STRANGE-COLUMN 

OCCURS 

10  TIMES. 

04  STRANGE- 

ARRAY 

USAGE  IS  COMPUTATIONAL-2. 

01 

PRINT- FORMAT. 

02 

FILLER 

PICTURE 

X VALUE  SPACES. 

02 

PRINT-LEADER 

PICTURE 

X (40)  VALUE  SPACES. 

02 

FILLER 

PICTURE 

X (7)  VALUE  'MEAN=*. 

02 

PRINT-MEAN 

PICTURE 

Z (6)  . 9 (6)  . 

02 

FILLER 

PICTURE 

X(3)  VALUE  '. 

02 

FILLER 

PICTURE 

X(15)  VALUE  'VARIANCE 

02 

PRINT-VARIANCE 

PICTURE 

Z(6)  .9(6)  . 

02 

FILLER 

PICTURE 

X(3)  VALUE  ',  '. 

02 

FILLER 

PICTURE 

X (24) 

VALUE  'STANDARD 

DEVIATICN= •- 

02 

PRINT-STANDARD- DEVIATION 

PICTURE  2 (6)  . 9 (6)  . 

PHOCEDURJi  DIVISION. 
A SECTION. 


A1 OO-OPEN-FILES. 

OPEN  INPUT  STRANGE-FILE 
OUTPUT  PRINT-FILE. 

A1 10-INITIALIZE-ARRAY. 

PERFOKK  A300-ZERO-ARRAY  THRU  A300-EXIT 

VARYING  I FROM  1 BY  1 UNTIL  I EgUAL  11 
AFTER  J FROM  1 BY  1 UNTIL  J EgUAL  11. 

A 1 <!0  • «F  AD-STRANGE-f  ILE. 

READ  STRANGE-FILE  AT  END  GO  TO  A1 40-COMPUTE-MEAN. 

A1  30-CREATE-ARR  AY. 

IF  RECORD-TYPE  EQUAL  *1* 

PERFORM  A3 10-TYPE- 1-MOVE  THRU  A310-EXIT. 

IF  RECORD-TYPE  EQUAL  '2* 

PERFORM  A 320-TYPE-2-MOVE  THRU  A320-EX1T. 

IF  RECORD-TYPE  EQUAL  '3* 

PERFORM  A330-TYPE- 3-MOVE  THRU  A330-EXIT. 

IF  RECORD-TYPE  EQUAL  *4* 

PERFORM  A340-TYPE-4-MOVE  THRU  A340-EXII. 

GO  TO  A120-READ-STRANGE-FILE. 


» 
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ai40-coi1pc;te-mean, 

PERFORM  A350-SUM  THRU  A350-EXIT 

VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 

AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

DIVIDE  SUMS  BY  100  GIVING  MEAN  ROUNDED. 

A1 50- VARIANCE- STANDARD- DEV  I ATE. 

PERFORM  A360-SUM-OF-SQUAKES  THRU  A360-EXIT 
VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 

AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

COMPUTE  VARIANCE  = (SUM-OF-SQUARES  - SUMS  2)  / 9900. 
COMPUTE  STANDARD-DEVIATION  = VARIANCE  .5. 

MOVE  MEAN  TO  PRINT-MEAN. 

MOVE  VARIANCE  TO  PRINT-VARIANCE. 

MOVE  STANDARD-DEVIATION  TO  PRINT-STANDARD-DEVIATION- 
MOVE  'THE  VALUES  FOR  THE  ORIGINAL  ARRAY  ARE'  TO  PRINT-LEADER. 
WHITE  PRINT-LINE  FROM  PRINT-FORMAT 
AFTER  POSITIONING  1 LINES- 
A165-TEST. 

PERFORM  A170-COMPUTE-2ND-MEAN 

PERFORM  A170-COMPUTE-2ND-MEAN  UNTIL  I EQUAL  1. 


PERFORM  2100  THRU  2101. 

PERFORM  2100  THRU  2101  UNTIL  I EQUAL  1. 
GO  TO  2101. 

2100. 


PERFORM  2102  THRU  2103  UNTIL  I IS  GREATER  THAN  J- 
GO  TO  2103. 

2102. 


IF  I EQUAL  11  THEN 
PERFORM  2500  THRU  2501 
ELSE 

PERFORM  2502  THRU  2503- 


GO  TO  2103. 

210  3. 


COMPUTE  CASE1 
GO  TO  2107. 

GO  TO  2108. 
LABEL-001. 

GO  TO  2108. 
LABEL-002. 


= (K). 

COMPUTE  1=1. 
COMPUTE  I = 12. 
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GO  TO  ZlOd. 

Z107. 

GO  TO 

LABEL-001, 

LABEL-002, 

DEPENDING  ON  CASE1. 

Z1  08. 


GO  TO  2101. 

Z10  1. 


A170-COMPUTE-2ND-MEAN. 

MOVE  ZEROS  TO  SUMS. 

PERFORM  A350-SUM  THRU  A350-EXIT 

VARYING  I FROM  1 BY  1 UNTIL  I EgUAL  11 
AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

DIVIDE  SUMS  BY  100  GIVING  MEAN  BOUNDED. 
A180-2ND-VAR-STANDARD-DEVIATE. 

MOVE  ZEROS  TO  SUM-OF-SQU ARES. 

PERFORM  A360-SUM-OF-SQUARES  THRU  A360-EXIT 
VARYING  I FROM  1 BY  1 UNTIL  I EQUAL  11 
AFTER  J FROM  1 BY  1 UNTIL  J EQUAL  11. 

COMPUTE  VARIANCE  = (S UM-QF-SQU ABES  - SUMS  *♦  2)  / 8800. 
COMPUTE  STANDARD-DEVIATION  = VARIANCE  ♦*  .5. 

MOVE  MEAN  TO  PRINT-MEAN. 

MOVE  VARIANCE  TO  PRINT-V ARI ANCE. 

MOVE  STANDARD-DEVIATION  TO  PRINT-STANDARD-DEVIATION. 

MOVE  ‘THE  VALUES  OF  THE  CONVERTED  ARRAY  ARE*  TO  PRINT-LEADER. 
WRITE  PRINT-LINE  FROM  PRINT-FORMAT 
AFTER  POSITIONING  2 LINES. 

A190-CLOSE-FILES. 

CLOSE  STRANGE-FILE 
PRINT-FILE. 

STOP  RUN. 

A300-ZERO-ARRAY. 

COMPUTE  STR ANGE-ARRAY  (I,  J)  = 0. 

A300-EXIT. 

EXIT. 

A3  10-TYPE- 1-MOVE. 

MOVE  VALUE-1  TO  STRANGE-ARR AY  (ROW,  COLUMNS). 

AJ10-EXIT. 

EXIT. 

A320-TYPE- 2-MOVE. 

MOVE  VALUE-2  TO  STRANGE-ARRAY  (ROW,  COLUMNS). 

A320-EXIT. 

EXIT. 

A330-TYPE-3-MOVE. 

MOVE  VALUE-3  TO  STRANGE-ARRAY  (ROW,  COLUMNS). 

A330-EXIT. 

EXIT. 
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A340-TYPE-4-MOVE. 

MOVE  VALUE-4  TO  STB ANGE-ARHAY  {ROW,  COLUMNS). 
A340-EXII. 

EXIT. 

A350-3UM. 

ADD  STRANGE-AHRAY  (1,  J)  TO  SUMS. 

A350-EXIT. 

EXIT. 

A3  60-SUM-OP-SQUARES. 

COMPUTE  sum-op-squares  = SUM-OP-SQUARES  + 

STRANGE-ABRAY  (I,  J) 


A360-EXIT. 

EXIT. 


Z500. 


♦ * 2. 


COMPUTE  1=1. 


Z501. 

Z504. 


COMPUTE  J = 20 

IP  K EQUAL  1 

COMPUTE  K = 2 
ELSE  NEXT  SENTENCE. 


Z505. 

Z508. 


CCHPUIE  J = 6. 


Z509. 

Z506. 


IF  K EQUAL  5 THEN 

PERFORM  Z508  THRU  Z509. 


COMPUTE  J = 21 


COMPUTE  CA3E1  = (K). 

GO  TO  Z111. 

GO  TO  Z112. 

LABELA-001.  COMPUTE  I = 99 

GO  TO  Z112. 
LA3ELA-002. 


COMPUTE  I 


9 
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GO  TO  Z112. 

Z1  n, 

GO  TO 

LABELA-001, 

LABELA-002, 

DEPENDING  ON  CASE1, 

Z1  12. 


Z507- 

Z502. 

IF  J EQUAL  11  THEN 
PEaFORM  Z504  THRU  Z505 

ELSE 

PERFORM  Z506  THRU  Z507. 


COMPOTE  J = 22 


PERFORM  Z113  THRU  Z114  VARYING  I FROM  1 BY  1 


UNTIL  I EQUAL  11 


GO  TO  Z114, 

Z1  13. 


COMPUTE  J = 97 


GO  TO  Z114. 

Z1  14. 


Z503 
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The  job  control  iangudge  tor  running  the  pre-processor 
on  an  IBM  360/370  follows: 

//*********  *^^***0***^^***  *********  4************  ********* 

//iTEPi  EXEC  PLIXCLO, PARM='OPT (2) * 

//SYSPhINT  DO  DUMMY 

//*  CHANGE  DUMMY  TO  3YS0UT=A  FOR  A SOURCE  LISTING  Of  THE 

//♦  FIRST  JOB  STEP  OF  THE  PHE-PfiOCESSOR 

//SYSIN  DD  DSNAME=IE212,ST£P1 ,DISP=SHR 

//*  IE212.STEP1  IS  THE  DATA  SET  CONTAINING  THE  SOURCE 
//*  PROGRAM  FOR  THE  FIRST  JOB  STEP  OF  THE  PRE-PHOCESSOfi 
//GO.SYSPRINT  DU  DUMMY 

//*  REMOVE  THIS  CARD  TO  GET  A LISTING  OF  THE  ORIGINAL 
//*  COBOL  PROGRAM 

//GO. SYSIN  DD  * 

//*  PLACE  THE  COBOL  DECK  HERE 

//GO. ERRORS  DD  SYSOUT=A  *PRINT  OUT  ERROR  MESSAGES 

//GO. OUTPUT  DD  DSNAME=&6TEMP1 ,DISP= (NEW,  PASS)  , 

//  SPACE=  (TRK,  (3,3)  ,RLSE)  ,UNIT=DISK, 

//  DCB= (RECFM=FB,LRECL=80,BLKSIZE=800) 

//*  TEMPORARY  DATA  SET  TO  STORE  PROGRAM 

//GO. BOTTOM  DD  DSN AME=6STEH P2 , D IS P= (NE W , PASS)  , 

//  SPACE=(TRK, (3,3) ,RLSE) , UNIT=DISK, 

//  DCB=  (RECFM,F3,LRECL=80,BLKSIZE=800) 

//*  ANOTHER  TEMPORARY  DATA  SET  USED  BY  THE  FIRST 

//*  JOB  STEP 

//***************************************************** 

//STEP2  EXEC  PLIXCLG, PARM^'OPT  (2)  • 

//SYSPRINT  DD  DUMMY 

//*  CHANGE  DUMMY  TO  SYSOUT=A  FOR  A SOURCE  LISTING  OF 

//*  THE  SECOND  JOB  STEP  OF  THE  PR E-PROCESSOH 

//SYSIN  DD  DSNAME=IE212.STEP2,DISP=SHR 

//♦  IE212.STEP2  IS  THE  DATA  SET  CONTAINING  THE  SECOND 

//*  JOB  STEP  OF  THE  PRE-PROCESSOR 

//GO. SYSIN  DD  DSNAME=66TEMP1 ,DISP=  (OLD, DELETE) 

//  DD  DSNAME=66TEMP2, DISP= (OLD, DELETE) 

//*  TAKE  THE  OUTPUT  FROM  THE  FIRST  JOB  STEP  AS  INPUT 

//GO. OUT  DD  D3NAME=66TEMP3,DISP=(NEW,PASS)  , 

//  SPACE=  (TRK,  (3, 3)  ,RLSE)  ,UNIT  = DISK, 

//  DCB=  (RECFM  = FB,LRECL  = 80,B1KSIZE=800) 

//♦  OUTPUT  FROM  THIS  JOB  STEP  TO  BE  PASSED  TO  THE 

//♦  TO  THE  NEXT  JOB  STEP — THE  COBOL  COMPILER 

//GO. ERRORS  DD  SYSOUT=A  *PRINT  OUT  ERROR  MESSAGES 

y /*******************  **^,*^  *********************  ******** 

//STEP3  EXEC  COBUCLG, PARM=* **PLACE  FARMS  DESIRED  HERE**' 
//SYSUT5  DD  DSN=66UT5,UNIT=SYSDA,SPACE=  (CYL,5)  ,D1SP=(NEW,PASS) 
//COB. SYSIN  DD  DSN AME=&6TEMP3 , DISP=  (OLD , DELETE) 

//GO.SXEPLIB  DD  DSN AM E=S YS 1 . COBLIB, DISP=SHR 
//*  PLACE  NECESSARY  GO.  CARDS  HERE 

The  joo  control  language  given  here  will  have  to  be  modified 


depending  on  the  particular  COBOL  and  PL/1  procedures  that 
are  available  and  the  requirements  that  they  entail.  If  it 
is  not  desirable  to  maintain  the  capability  to  print  out  the 
source  listing  of  the  pre-processor,  it  would  be  much  more 
efficient  to  compile  and  linh-edit  both  job  steps  and  make 
the  whole  pre- processor  a cataloged  procedure  with  the  out- 
put options  as  parameters  to  the  procedure. 


